ObJectRelationalBridge

Hi Thomas,

<snip>

>
> Mmh. This is a good idea. But I think it is conflicting with the
> hashtable concept. The hashtable is used to allow quick lookup of locked
> objects during a tx.

I think I have found a solution for this that is able to tell the order of
the added objects while maintaining the speed of the hashtable for lookups.
Only removing objects from the table would be more expensive.

>  > 2.) Change the order how dependent objects are
> inserted/updated/deleted.
>  > Referenced objects are always the master, collections are always the
> detail
>  > to an object. Currently I cannot think of a case where this could be
>  > different.
>  >
>
> This is exactly the depency graph I'm talking about!
> By analysing the ReferenceDecsriptors and the CollectionDescriptors it
> is possible to determine which object has to be inserted first etc.

So this is easy. TransactionImpl.register already resolves References and
Collections, just the order has to be changed.

I just added the RI test case to CVS and I hope I can commit the fix today.

<snip>

best regards,
Florian

Hi

Florian wrote:
> 
> I think I have found a solution for this that is able to tell the order of
> the added objects while maintaining the speed of the hashtable for lookups.
> Only removing objects from the table would be more expensive.
> 


great news!
removing of objects is not an issue!



>>
> 
> So this is easy. TransactionImpl.register already resolves References and
> Collections, just the order has to be changed.
> 



Right! Sorry, I forgot to mention that register() can be used as a sample.


> I just added the RI test case to CVS and I hope I can commit the fix today.
> 


I just loaded your stuff from CVS and there is only one failure for the 
delete TestCase.
The changes look quite straightforward.

thanks,

Thomas

Hi,

> I just loaded your stuff from CVS and there is only one failure for the
> delete TestCase.
> The changes look quite straightforward.

The failure within the delete testcase looks like it exposes another
problem. If the foreign key ist part of the details primary key, the objects
are retrieved correctly and the deletion works.

If the foreign key is not part of the primary key the query doesn't return
the correct objects. In the test case there are five different objects
associated to a master object, but the query returns the same object five
times, therefore there is still a fk constraint violation, because four
objects remain related to the master object.

lg,

Florian, der trotz strahlendem Sonnenschein in Wien herumhackt...