On Sun, 14 Nov 2004 17:35:04 +0100, Łukasz Korzybski <[EMAIL PROTECTED]> wrote:
>Dnia czwartek, 11 listopada 2004 13:49, Gerhard Grosse napisał: >> On Wed, 10 Nov 2004 21:26:22 +0100, Grzegorz Pypec <[EMAIL PROTECTED]> >> >> wrote: > >> >> Instead of tx.checkpoint() you can use ((TransactionExt) tx).flush(), >> which flushes all SQL to the DB without commit. >> >> However, normally OJB does a pretty good job in ordering the SQL >> correctly. Could it be that you have some cyclic references in your >> object model (e.g. A->B and B->A)? >> >> Gerhard > >I suppose that after invoking flush(), transaction holds db connection opened >all the time so we can later rollback? > Obviously, the connection has to stay open until the transaction commits. >From JavaDoc: > > "Calling flush flushes persistent object modifications made within the ODMG >transaction since the last checkpoint to the underlying database transaction" > >If so, it is not a good news :) > >Is anyone has similar problem with deleting referenced objects? I have exactly >the same problem as Grzegorz Pypec with ojb1.0.1 nad PostgreSQL 7.4 (jdbc 3.0 >drv). >I can't believe that such essential feature doesn't work. >From looking at the source of ObjectEnvelopeTable.java I see 2 or 3 potential shortcomings of OJB's SQL ordering: - the ordering is based on the modified state of the objects only; therefore if a reference in object A is set to null, OJB does not see that before modification A referenced an object B to be deleted. If B has a corresponding collection mapping containing A, OJB might resolve the dependency from this end, but if there is no collection mapping, no ordering will occur. - 1:n and m:n collections are treated in the same way, although the FK-location in the DB is quite different. - OJB' ordering algorithm is 'greedy' in the sense that once an object modification has been put into the ordered list, it will stay at this position even if later reasons are found that would require to move it to a position further down. If anyone has a better solution... Gerhard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
