double references to one object (was: [OTM] bug with most simple use case)

[Joerg Heinicke <jo...@gmx.de>]

On 18.05.2004 21:20, Oleg Nitz wrote:

>>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?
> 
> All of the above :)
> Very simple: object identity uniquely identifies the object. 
> AFAIK Sun JDO spec also treats object identity in similar way,
> which differs from the way of standard Java APIs.

Ok, sounds logical :)

I found today another buggy behaviour, but have not look deeply enough 
into it, what more or less means I have no test case until now.
Just to give the idea: I have a legalcase and a depending collection of 
events (as history). Some of those events have again a depending 
collection of objects (here: payment by installment, installment rates). 
As long as the event collection is valid (here: no other event occured 
changing the payment method) the collection is also referenced on the 
legalcase directly. But if the payment method changes the collection on 
the legalcase will be set to null. Unfortunately a 
makePersistent(legalcase) does not cut the reference from each 
installment rate to the legalcase. After a server restart the legalcase 
object will be restored with the installment rates collection though it 
was set to null before.

installment rate table:
id | period | amount | eventId | legalcaseId
  1 |     30 |    100 |       1 |           1
  2 |     60 |    100 |       1 |           1
  3 |     90 |    100 |       1 |           1

After setting installment rate collection to null on the legalcase and 
makePersistent() the legalcaseId should be 0.

IIRC I already had a similar issue some time ago. At that time I removed 
this double reference as it was more disturbing than helpful from the 
application POV, but here it is more than just helpful. Is this 
requirement to pretentiously?

Joerg

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