[jira] [Commented] (JDO-756) Enhance PK to avoid LongIdentity/StringIdentity dependencies
[
https://issues.apache.org/jira/browse/JDO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15516828#comment-15516828
]
Craig L Russell commented on JDO-756:
-
When we designed application identity we looked at ways of simplifying the job
of the application writer and came up with several helper classes that remove
the requirement for "repetitive work". For most cases (single field application
identity) there is no extra coding. But for compound primary and foreign keys,
more work is needed.
Perhaps you could write a more complete description of how you would like to
see it work. We're always interested in improving the developer experience.
Thanks,
Craig
> 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)
[jira] [Commented] (JDO-756) Enhance PK to avoid LongIdentity/StringIdentity dependencies
[
https://issues.apache.org/jira/browse/JDO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (JDO-756) Enhance PK to avoid LongIdentity/StringIdentity dependencies
[
https://issues.apache.org/jira/browse/JDO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
