[ 
https://issues.apache.org/jira/browse/JDO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463060#comment-15463060
 ] 

joseaio commented on JDO-756:
-----------------------------

> 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)

Reply via email to