Hi Andrus,
On Jun 10, 2007, at 4:42 AM, Andrus Adamchik wrote:
>> 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.
With to-many relationships you map the relationship to a field in the
non-pk table and all the entities that are related can be counted and
operated on. It's not clear to me that uniquing is of value when you
don't define a unique behavior in the database.
Given that there is a database schema that makes sense for the
application, I don't see any problem with mapping that to Java
objects. You just cannot assign stronger identity inside the VM than
exists in the database.
Craig
>
> 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
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russel..un.com
P.S. A good JDO? O, Gasp!
This archive was generated by hypermail 2.0.0 : Sun Jun 10 2007 - 13:13:14 EDT