On Sep 26, 2008, at 9/2610:04 AM , Andrus Adamchik wrote:
>>
>> I can check into how they handle the non-explicit-ordering-column
>> case if you'd like.
>
> I would appreciate that. Maybe that join is their answer. Not
> pretty at all.
>
Nope, it's not. But it is their answer, apparently (note that they
documentation on hibernate core doesn't seem to mention this; they say
you have to provide an explicit "index" for list ordering). I took a
working hibernate mapping/project and stepped through the sql events.
Test looks something like (pseudocode)
Parent p = new Parent();
p.getChildren().add(new Child(0));
p.getChildren().add(new Child(1));
session.save(p);
assert children in correct order
p.getChildren().add(1,new Child(2));
assert children in correct order (child(0), child(2), child(1))
save(p);
p = refetch p from database using a new session
assert children in correct order (child(0), child(2), child(1))
And the test passes.
So, looking at the sql events, the table structure comes out like:
Parent table one to many Parent_Child (join table) many to one Child
Now when looking at the sql log, the set of events is:
insert parent
insert child0
insert child1
insert parent1_child0 join row
insert parent1_child1 join row
insert child2
delete from parent_child where parent is 1
insert parent1_child0 join row
insert parent1_child2 join row
insert parent1_child1 join row
So they achieve the ordering by relying on the default returned order
from the database of the join table.
At least, that's what hibernate does when working with hsqldb. It may
be different for other database types.
If you were going to map the relationship w/out the join table, then I
imagine hibernate would complain and make you specify an index, but I
haven't tried that.
Robert
>> Interestingly, by default, a one-to-many relationship in hibernate
>> is still handled through an intermediary join table.
>> You can override that, of course, but I thought it a curious default.
>
> Ugh, I am sure it sucks for the (unsuspecting) users.
> Andrus
>
> On Sep 26, 2008, at 6:01 PM, Robert Zeigler wrote:
>
>> HIbernate actually handles this.
>> When you define a relationship as a list, hibernate ensures that
>> the items are always fetched in the same order.
>> I haven't dug into the details of how to do this. I know its
>> possible to explicitly declare a "sort column", but generally
>> unnecessary;
>> I assume that in the absence of an explicit sort column, hibernate
>> (silently) adds a sort column for you.
>>
>> I can check into how they handle the non-explicit-ordering-column
>> case if you'd like.
>>
>> Interestingly, by default, a one-to-many relationship in hibernate
>> is still handled through an intermediary join table.
>> You can override that, of course, but I thought it a curious
>> default. That said, by silently handling relationships that way,
>> it would allow them to add the sort information to the join table,
>> which has no object corollary so your object model is uncluttered.
>>
>> Robert
>>
>> On Sep 26, 2008, at 9/269:48 AM , Andrus Adamchik wrote:
>>
>>>
>>> On Sep 26, 2008, at 2:41 AM, Chris Murphy wrote:
>>>
>>>> Wouldn't it be a good idea for the generated methods to have the
>>>> extra int argument?
>>>
>>> It is a bit more involved than that. The problem with including
>>> this in Cayenne is that it won't work in a more general case. E.g.
>>> if you add an object at a particular index, and the master object
>>> is later invalidated and refetched, the order will be lost. Or if
>>> it is refetched by another user. So Scott's answer was essentially
>>> correct.
>>>
>>> We tried to solve it from another angle, by defining a certain
>>> column as the "ordering" column to instruct Cayenne to order
>>> fetched relationship lists. It is still on the table, but it is
>>> also hairy...
>>>
>>> For now I can't think of a clean generic solution that would map
>>> to a DB. The ordering column is the closest I can think of.
>>>
>>> Thanks,
>>> Andrus
>>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Fri Sep 26 2008 - 15:27:53 EDT