Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Design Review - MOXy Equivalents of Relevant JPA Annotations

Hi Shaun,

If the Root class looked like this:
public class Root {
    public List<Employee> employees;
    public List<Address> buildingAddresses;
}
I would expect that after unmarshalling the doc the Root object would have a list of three Addresses and a list of  two Employees. 

Employee 101 would have Address:
id=100
street=45 O'Connor St., Suite 400
suite=400
city=Ottawa
postal=K1P1A4

And Employee 102 would have Address:
id=100
street=99 Some St.
suite=1001
city=Kanata
postal=K0A3m0
--Dave


Shaun Smith wrote:
Hi Dave,

On 26/8/2010 10:56 AM, David McCann wrote:
Hey Shaun,

Yes,
an abstract class would declare an xml-discriminator-node and not provide an xml-discriminator-value.
Sounds good.
In regards to the xml-join-node example I can see how you found it confusing.  Let me try a slightly different example to clarify what I'm trying to accomplish:
Given the example below, what would the result of unmarshalling the document?

    Shaun
// eclipselink-oxm.xml
<java-types>
    <java-type name="org.example.Employee">
        <xml-root-element name="employee-data" />
        <java-attributes>
            <xml-attribute java-attribute="id" />
            <xml-element java-attribute="address">
                <xml-join-nodes>
                    <xml-join-node xml-path="work-address/@id" referenced-xml-path="@id" />
                    <xml-join-node xml-path="work-address/@city" referenced-xml-path="city" />
                </xml-join-nodes>
            </xml-element>
        </java-attributes>
    </java-type>
    <java-type name="org.example.Address">
        <xml-root-element name="business-address" /> 
        <java-attributes>
            <xml-attribute java-attribute="id" xml-key="true" />
            <xml-element java-attribute="city" xml-key="true" />
        </java-attributes>
    </java-type>
</java-types>

// sample instance document
<root>
    <employee-data id="101">
        <work-address id="100" city="Ottawa" />
    </employee-data>
    <employee-data id="102">
        <work-address id="100" city="Kanata" />
    </employee-data>
    <business-address id=100>
        <street>99 Some St.</street>
        <suite>1001</suite>
        <city>Kanata</city>
        <postal>K0A3m0</postal>
    </business-address>
    <business-address id=100>
        <street>45 O'Connor St., Suite 400</street>
        <suite>400</suite>
        <city>Ottawa</city>
        <postal>K1P1A4</postal>
    </business-address>
    <business-address id=200>
        <street>1 Anystreet Rd.</street>
        <suite>9</suite>
        <city>Ottawa</city>
        <postal>K4P1A2</postal>
    </business-address>
</root>

Please let me know if you have any other questions.

Cheers,
Dave




Shaun Smith wrote:
Hi Dave,

    In an inheritance hierarchy would an abstract class declare an xml-discriminator-node and just not provide an xml-discriminator-value?

    In the sample document:
<root>
    <employee-data id="100">
        <address emp-id="100" type="HOME" />
    </employee-data>
    <address-data>
        <empId>100</empId>
        <type>HOME</type>
        <street>99 Some St.</street>
        <city>Kanata</city>
        <postal>K0A3m0</postal>
    </address-data>
    <address-data>
        <empId>100</empId>
        <type>WORK</type>
        <street>45 O'Connor St., Suite 400</street>
        <city>Ottawa</city>
        <postal>K1P1A4</postal>
    </address-data>
    <address-data>
        <empId>200</empId>
        <type>HOME</type>
        <street>1 Anystreet Rd.</street>
        <city>Ottawa</city>
        <postal>K4P1A2</postal>
    </address-data>
</root>
Do I understand that the second and third addresses are not owned by employee 100?  This example is similar to the "standard" EclipseLink JPA Employee model with Employee having collection of PhoneNumbers.  In that example PhoneNumber has a composite key of the employee's id and type--which ensures in a relational database that a given employee could not have two phone numbers of the same type.  In the relational example, unlike in your example, the relationship to Employee is purely through the PhoneNumber's employee id, and not the type (see below).

I guess what I'm asking is, can this same type of reference resolution be expressed: composite key but only part of it used to resolve a relationship? 

Also, the repetition of the Employee's id in both "id" and "emp-id" seems redundant:
<root>
    <employee-data id="100">
        <address emp-id="100" type="HOME" />


        Shaun



public class Employee implements Serializable {
    @Id
    @Column(name = "EMP_ID")
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    private long id;
...   
    @OneToMany(mappedBy = "owner", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<PhoneNumber> phoneNumbers = new ArrayList<PhoneNumber>();


-----------------

@Entity
@Table(name = "PHONE")
@IdClass(PhoneNumber.ID.class)
public class PhoneNumber implements Serializable {

    @Id
    @Column(updatable = false)
    private String type;
...
    @Id
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "EMP_ID")
    private Employee owner;




On 23/8/2010 4:00 PM, David McCann wrote:
All,

Please review the design Wiki here, and provide any feedback you may have.

--
Oracle
David McCann | Principal Software Engineer | +6132884636
Oracle Server Technologies, EclipseLink Product
ORACLE Canada | 45 O'Connor St., Suite 400 | Ottawa, Ontario | K1P 1A4
Green Oracle Oracle is committed to developing practices and products that help protect the environment
_______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

--
Oracle
Shaun Smith | Principal Product Manager
Phone: +19055023094
Oracle Server Technologies, Oracle TopLink
ORACLE Canada | 110 Matheson Boulevard West, Suite 100, Mississauga, Ontario | L5R 3P4

Green
              Oracle Oracle is committed to developing practices and products that help protect the environment

_______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

--
Oracle
David McCann | Principal Software Engineer | +6132884636
Oracle Server Technologies, EclipseLink Product
ORACLE Canada | 45 O'Connor St., Suite 400 | Ottawa, Ontario | K1P 1A4
Green Oracle Oracle is committed to developing practices and products that help protect the environment
_______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

--
Oracle
Shaun Smith | Principal Product Manager
Phone: +19055023094
Oracle Server Technologies, Oracle TopLink
ORACLE Canada | 110 Matheson Boulevard West, Suite 100, Mississauga, Ontario | L5R 3P4

Green
          Oracle Oracle is committed to developing practices and products that help protect the environment

_______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

--
Oracle
David McCann | Principal Software Engineer | +6132884636
Oracle Server Technologies, EclipseLink Product
ORACLE Canada | 45 O'Connor St., Suite 400 | Ottawa, Ontario | K1P 1A4
Green Oracle Oracle is committed to developing practices and products that help protect the environment

Back to the top