Hi Abe,
I think I now understand your point, which I missed earlier. You
don't see a need for a primary key to be defined on a join table.
The issue is whether a compliant JDO implementation can require that
a join table must have a primary key if it is used to implement a
multi-valued field (collection or map).
Apparently, JPOX requires this, and there is nothing in the spec
currently that addresses the issue at all. Unless we change the spec
to disallow the JPOX implementation, it seems that it is de facto a
portability issue.
What are the implications of not having a primary key in the join
table? The constraint that the Map keys (or Set elements) must be
unique must be enforced by the application (the JDO implementation).
This implies that the entire Map or Set must be instantiated in
memory in order to prevent duplicates. [I don't see how to implement
a lazy loading strategy for such Maps or Sets.]
What else?
Craig
On Nov 21, 2005, at 6:42 PM, Abe White wrote:
If owner_id is primary key and nothing else, we will not be able
to store more
than one instance of Dog for each owner. Thus, we need a new
column to be part
of the primary key.
Or the table could have *no primary key at all*, which is what I'm
arguing should be perfectly portable.
Right. They have no persistent identity. Therefore, if you want to
use an embedded PersistenceCapable as a key, you need to identify
one of the embedded fields as a key for the purpose of the map.
The alternative is to simply disallow using an embedded
PersistenceCapable as a key in a map if the class is defined as
datastore identity. But this seems pretty arbitrary.
The only requirements for using objects in a Map in Java are that
they implement hashCode and equals properly. How do you go from
that contract to "needs a primary key in the database map table"?
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
