[
https://issues.apache.org/jira/browse/JDO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462940#comment-15462940
]
Andy Jefferson commented on JDO-756:
------------------------------------
> In Customer and Supplier classes: the id is long (not LongIdentity)
Well no. The Field/Property is of type long. The ID is of type LongIdentity
(because you didn't provide an ObjectIdClass).
The *only* reason there is a dependency on javax.jdo.identity.XXXIdentity is
because the example hasn't defined their own ObjectIdClass for Customer or
Supplier. If the user had a composite Id in Customer then they would put their
ObjectIdClass in the compound identity PK for BusinessRelation. So it is
totally consistent how compound identity relations are modelled currently.
Suggest that you go and sketch out Supplier and Customer each using multiple PK
fields (and the subsequent identity) and see how that fits, and see why it is
done as it is.
> Enhance PK to avoid LongIdentity/StringIdentity dependencies
> ------------------------------------------------------------
>
> Key: JDO-756
> URL: https://issues.apache.org/jira/browse/JDO-756
> Project: JDO
> Issue Type: Improvement
> Reporter: joseaio
> Fix For: JDO 3.2
>
>
> Please see: JDO Guides : M-N Attributed Relation
> http://www.datanucleus.org/products/accessplatform_3_1/guides/jdo/many_many_attributed/index.html
> public class BusinessRelation{
> · private Customer customer; // PK
> · private Supplier supplier; // PK
> BusinessRelation.PK requires:
> · public LongIdentity customer; // LongIdentity dependency
> · public LongIdentity supplier; // LongIdentity dependency
> In Customer and Supplier classes: the id is long (not LongIdentity)
> · private long id; // PK
>
> I think more convenient enhance BusinessRelation.PK to allow long types (and
> remove LongIdentity/***Identity dependencies):
> BusinessRelation.PK
> · public long customer; // Use long as Customer.id field
> · public long supplier; // Use long as Supplier.id field
> note: the same rule for other basic types (String, Dates, Integer, Long,
> Byte...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
