[ https://issues.apache.org/jira/browse/JDO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463060#comment-15463060 ]
joseaio edited comment on JDO-756 at 9/4/16 3:15 PM: ----------------------------------------------------- > Well no. The Field/Property is of type long. The ID is of type LongIdentity > (because you didn't provide an ObjectIdClass). I think, this option must be transparent for my domain classes and PKs Is mandatory create custom PK for Customer & Supplier for single basic (Long, String) field PK? see as a repetitive work... IMHO, is more intuitive to use basic types in this case and resolve internally: 1.- in enhancement check: JDOAdapter 2.- and when copy to/from ObjectId: dnCopyKeyFieldsFromObjectId and dnCopyKeyFieldsToObjectId I really see how is done (internal use of ObjectIds), but I proposed transparent use of that classes without javax.jdo.identity.XXXIdentity dependency · when I declare custom PK for Customer/Supplier the fields for it must be defined using simple types (String, Long) not XXIdentity types => I really see sense for compound identities on Customer/Supplier but not when PKs are single field Andy, thank you for your previous response was (Author: joseaio): > Well no. The Field/Property is of type long. The ID is of type LongIdentity > (because you didn't provide an ObjectIdClass). I think, this option must be transparent for my domain classes and PKs Is mandatory create custom PK for Customer & Supplier for single basic (Long, String) field PK? see as a repetitive work... IMHO, is more intuitive to use basic types in this case and resolve internally: 1.- in enhancement check: JDOAdapter 2.- and when copy to/from ObjectId: dnCopyKeyFieldsFromObjectId and dnCopyKeyFieldsToObjectId I really see how is done (nternal use ObjectId), but I proposed transparent use of that classes without javax.jdo.identity.XXXIdentity dependency · when I declare custom PK for Customer/Supplier the fields for it must be defined using simple types (String, Long) not XXIdentity types => I really see sense for compound identities on Customer/Supplier but not when PKs are single field Andy, thank you for your previous response > 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)