db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [OTM] bug with most simple use case - the story goes on :)
Date Mon, 17 May 2004 19:49:32 GMT
On 15.05.2004 22:11, Oleg Nitz wrote:

> Hi Jeorg,
> 
> It's fixed. Insert after delete didn't change the state of object, so it was 
> deleted.

Thanks for the fix, it works. Just curious about another consequence of 
the code refactoring: I wrote in this thread:

"The reason for the non-working of the code in contrary to the March 
code is that in updateAddresses() the items in the collection 
newAddresses and oldAddresses are different, the equals() or here 
contains() does no longer work."

Due to this change in

private Collection updateAddresses(Collection newAddresses) {
// massively shortened
     Collection oldAddresses = _conn.getCollectionByQuery(q);
     Iterator oldAddressesIterator = oldAddresses.iterator();

     while (oldAddressesIterator.hasNext()) {
         Address oldAddress = (Address)oldAddressesIterator.next();
         if (!newAddresses.contains(oldAddress)) {
             _conn.deletePersistent(oldAddress);
         }
     }

the test !newAddresses.contains(oldAddress) always returns false. OJB 
handles it internally so that no db access will be done if not 
necessary, i.e. if the "same" elements (in OJB sense, but different in 
Java sense) will be readded in the same tx.

But the behaviour is a bit strange. Is this by 
intention/design/implementation?

Thanks again for the fix in time for the customer presentation tomorrow ;-)

Joerg

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message