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.
--
David
McCann | Principal Software Engineer | +6132884636
Oracle Server Technologies,
EclipseLink Product
ORACLE Canada | 45 O'Connor St., Suite 400 | Ottawa,
Ontario | K1P 1A4
 |
Oracle
is committed to developing practices and
products that help protect the environment
|
--
Shaun
Smith | Principal Product Manager
Phone: +19055023094
Oracle Server Technologies,
Oracle
TopLink
ORACLE Canada | 110 Matheson Boulevard West, Suite 100,
Mississauga,
Ontario | L5R 3P4
 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
--
David McCann | Principal Software Engineer |
+6132884636
Oracle Server Technologies,
EclipseLink
Product
ORACLE Canada | 45 O'Connor St., Suite 400 | Ottawa, Ontario |
K1P 1A4
 |
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
--
Shaun Smith | Principal Product Manager
Phone: +19055023094
Oracle Server Technologies, Oracle
TopLink
ORACLE Canada | 110 Matheson Boulevard West, Suite 100,
Mississauga, Ontario | L5R 3P4
Oracle is committed to developing practices and
products that help protect the environment
|
