If you can navigate to a single A via a relationship, to me that
implies that you have some unique constraint by which a single A is
associated with another row. And if you have a unique constraint,
then you can use that instead of a primary key.
True, and that constraint makes it possible to map a "virtual" PK in
Cayenne, so having a no-pk entity doesn't buy us anything in this case.
But in the remaining cases uniquing is clearly broken. This includes
to-many relationships and running multiple queries with overlapping
result sets.
Andrus
On Jun 9, 2007, at 11:27 PM, Craig L Russell wrote:
Hi Andrus,
On Jun 7, 2007, at 11:38 PM, Andrus Adamchik wrote:
On Jun 8, 2007, at 7:01 AM, Craig L Russell wrote:
Just FYI, when JDO reads data from tables without PK, it
internally creates a unique id, similar to a generated PK, for
the objects that it reads and these ids are discarded when no
longer needed. The fact that the mapping is for tables without PK
is known by the code that creates the temporary ids.
Craig
Hi Craig,
I can probably implement this in Cayenne in about 30 minutes, as
Cayenne has a notion of "temporary id" (normally used for new
uncommitted objects). The problem of course is uniquing. So say if
a DB row is fetched from a table via a query, resulting in object
A, and then later the same row is navigated to via a relationship
from another object, resulting in a second object B, distinct from
A. This breaks the fundamental assumption about object identity.
So we chose not to go this way.
If you can navigate to a single A via a relationship, to me that
implies that you have some unique constraint by which a single A is
associated with another row. And if you have a unique constraint,
then you can use that instead of a primary key.
Craig
