You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Oleg Nitz <on...@ukr.net> on 2004/05/14 00:30:39 UTC
Re: [OTM] bug with most simple use case - the story goes on :)
Hi Jeorg,
Sorry for doing nothing about OTM problems last time, I'll try to start doing
more.
On Thursday 22 April 2004 18:12, Joerg Heinicke wrote:
> BTW, did this test case made it into the CVS? I searched it, but could not
> find it.
It's here: SwizzleTests.testSomethingSimple()
Can you give me the diff, please?
Thank you for your patience,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
double references to one object (was: [OTM] bug with most simple
use case)
Posted by 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
Re: [OTM] bug with most simple use case - the story goes on :)
Posted by Oleg Nitz <on...@ukr.net>.
Hi Joerg,
On Monday 17 May 2004 22:49, Joerg Heinicke 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.
Regards,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OTM] bug with most simple use case - the story goes on :)
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Re: [OTM] bug with most simple use case - the story goes on :)
Posted by Oleg Nitz <on...@ukr.net>.
Hi Jeorg,
It's fixed. Insert after delete didn't change the state of object, so it was
deleted.
Regards,
Oleg
On Saturday 15 May 2004 01:44, Joerg Heinicke wrote:
> On 14.05.2004 00:30, Oleg Nitz wrote:
> > Hi Jeorg,
> >
> > Sorry for doing nothing about OTM problems last time, I'll try to start
> > doing more.
>
> No problem. I made it work for me doing the two iterations in two
> transactions, though this can obviously lead to data loss.
>
> I only found it strange that there was no reaction at all.
>
> >>BTW, did this test case made it into the CVS? I searched it, but could
> >> not find it.
> >
> > It's here: SwizzleTests.testSomethingSimple()
> > Can you give me the diff, please?
>
> Oh, don't know why I did not find it. The test diff is extremely easy.
>
> Joerg
>
>
> Index: SwizzleTests.java
> ===================================================================
> RCS file:
> /home/cvspublic/db-ojb/src/test/org/apache/ojb/otm/SwizzleTests.java,v
> retrieving revision 1.13
> diff -u -r1.13 SwizzleTests.java
> --- SwizzleTests.java 12 Apr 2004 16:32:42 -0000 1.13
> +++ SwizzleTests.java 14 May 2004 22:41:26 -0000
> @@ -475,6 +475,8 @@
> addresses = this.updateAddresses(addresses);
> addresses = this.getAddresses();
>
> + assertEquals("Collection of addresses must be 1. ", 1,
> addresses.size());
> +
> iter = addresses.iterator();
> while (iter.hasNext()) {
> Address address = (Address)iter.next();
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OTM] bug with most simple use case - the story goes on :)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.05.2004 00:30, Oleg Nitz wrote:
> Hi Jeorg,
>
> Sorry for doing nothing about OTM problems last time, I'll try to start doing
> more.
No problem. I made it work for me doing the two iterations in two
transactions, though this can obviously lead to data loss.
I only found it strange that there was no reaction at all.
>>BTW, did this test case made it into the CVS? I searched it, but could not
>>find it.
>
> It's here: SwizzleTests.testSomethingSimple()
> Can you give me the diff, please?
Oh, don't know why I did not find it. The test diff is extremely easy.
Joerg
Index: SwizzleTests.java
===================================================================
RCS file:
/home/cvspublic/db-ojb/src/test/org/apache/ojb/otm/SwizzleTests.java,v
retrieving revision 1.13
diff -u -r1.13 SwizzleTests.java
--- SwizzleTests.java 12 Apr 2004 16:32:42 -0000 1.13
+++ SwizzleTests.java 14 May 2004 22:41:26 -0000
@@ -475,6 +475,8 @@
addresses = this.updateAddresses(addresses);
addresses = this.getAddresses();
+ assertEquals("Collection of addresses must be 1. ", 1,
addresses.size());
+
iter = addresses.iterator();
while (iter.hasNext()) {
Address address = (Address)iter.next();
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org