Re: A specific question about the JDO specification and object-id classes
From: Oscar kind (oscar_at_danwa.net)
Date: Wed, 12 May 2004 17:37:38 -0000
Scott Morman <email@example.com> wrote:
> The problem is that in section 18.3 of the JDO 1.0.1 specification it
> states the following:
> "If the object-id class attribute is defined in any concrete class,
> then the objectid class itself must be concrete, and no subclass of
> the class may include the objectid-class attribute."
> This statement tells me that according to the specification that we
> cannot have an objectid per PersistenceCapable class. Section 18.3
> tells me the best that we can do is have an abstract objectid-class
> for each of the abstract PersistenceCapable classes and a single
> concrete objectid-class for the rest of PersistenceCapable classes for
> a particular class hierarchy.
> My question is, why does this limitation exist? What is the reasoning
> for preventing every PersistenceCapable class from having its own
> objectid-class that simply extends its parent's objectid-class.
The limitation ensures that the class that represents an objectid is not
abstract. It also ensures there is no loop, by stating that the objectid
class (and all its subclasses) may not contain the objectid attribute.
So you can have an objectid per persistence-capable class (the objectid's
can even have the same superclass), unless the objectid classes themselves
are also persistence-capable (which doesn't make sense: the id of a
business object is not a business object).
I assume however, that the objectid class does have some other limitations
(maybe it must be serializable). This however, I don't know.
-- Oscar Kind http://home.hccnet.nl/okind/ Software Developer for contact information, see website PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2