[
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:29 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 field PK? see
as a repetitive work...
· note: please, see Account.PK on "1-N Collection Relationship"
(http://www.datanucleus.org/products/datanucleus/jdo/orm/compound_identity.html#a1_N_coll_bi)
as example of repetitive work, for creating single field PKs.
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 field PK? see
as a repetitive work...
· note: please, see Account.PK on "1-N Collection Relationship"
(http://www.datanucleus.org/products/datanucleus/jdo/orm/compound_identity.html)
as example of 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
> 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)
