> 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
This archive was generated by hypermail 2.0.0 : Sun Jun 10 2007 - 07:42:40 EDT