|
Home > Archive > Apache JDO Project > September 2005 > Explicit SingleFieldIdentity in metadata?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Explicit SingleFieldIdentity in metadata?
|
|
| Matthew T. Adams 2005-09-23, 5:45 pm |
| Currently, section 18.6 of the JDO 2.0 PFD states that if for a class
identity-type="application", there is no objectid-class attribute, and there
is only one primary key field for that class, then the JDO implementation is
to use a SingleFieldIdentity subclass as the object id class. I don't see
why users couldn't use a SingleFieldIdentity subclass of their choice. As
such, I would also like for people to be able to use the names of the
SingleFieldIdentity subclasses as the value of the objectid-class attribute.
The implementation may or may not support certain combinations of type
conversions (object id class is StringIdentity, but the PC class uses an id
field of type int); widening combinations should be supported (object id
class LongIdentity with the PC class id field of type short, etc).
This is not a huge deal, but I don't see why we shouldn't support metadata
declarations of the form
<class name="Foo" identity-type="application"
objectid-class="javax.jdo.identity.StringIdentity">...
It's still spec-compliant, as "javax.jdo.identity.StringIdentity" is the
name of a valid object id class.
--matthew
Matthew T. Adams
Corporate Technical Advisor & Senior Consultant
Mobile: +1 253 732 1051
Phone: +1 206 331 3833
Fax: +1 815 331 0952
matthew.adams@xcalia.com
P.O. Box 24163
Federal Way, WA 98093
www.xcalia.com <http://www.xcalia.com/>
Xcalia makes implementing SOA easy with agile business intermediation
software that combines heterogeneous data with services to easily develop
and deploy transactional composite applications. Enterprises can quickly
respond to changing business requirements and dramatically reduce the costs
of data access and service integration.
| |
| Craig Russell 2005-09-24, 2:45 am |
| | |
| Craig Russell 2005-09-26, 2:45 am |
| Hi Matthew,
Let me try again, since apparently I didn't read your original message
carefully enough.
The issue with using a different type of single field identity from
the field type is that there are always both narrowing as well as
widening conversions. That is, if the user creates a LongIdentity for
an int field, then the long value needs to be narrowed in order to
store it. On the other hand, if the user uses a ShortIdentity for the
same field, there is a narrowing conversion needed when the
implementation creates the object identity during fetch from the
datastore.
That said, I don't see anything in the spec that disallows this usage,
but it's not required to be supported. It can be an unTCKtested vendor
extension.
Craig
On Sep 23, 2005, at 10:42 PM, Craig Russell wrote:
Hi Matthew,
Yes, users can explicitly identify the single field class of their
choosing as long as the field type matches the single field identity
class key type. No problem.
Craig
On Sep 23, 2005, at 3:31 PM, Matthew T. Adams wrote:
Currently, section 18.6 of the JDO 2.0 PFD states that if for a class
identity-type=3D"application", there is no objectid-class attribute, and
there is only one primary key field for that class, then the JDO
implementation is to use a SingleFieldIdentity subclass as the object
id class. I don't see why users couldn't use a SingleFieldIdentity
subclass of their choice. As such, I would also like for people to be
able to use the names of the SingleFieldIdentity subclasses as the
value of the objectid-class attribute. The implementation may or may
not support certain combinations of type conversions (object id class
is StringIdentity, but the PC class uses an id field of type int);
widening combinations should be supported (object id class
LongIdentity with the PC class id field of type short, etc).
This is not a huge deal, but I don't see why we shouldn't support
metadata declarations of the form
<class name=3D"Foo" identity-type=3D"application"
objectid-class=3D"javax.jdo.identity.StringIdentity">...
It's still spec-compliant, as "javax.jdo.identity.StringIdentity" is
the name of a valid object id class.
--matthew
|
|
|
|
|