You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Bruno CROS <br...@gmail.com> on 2006/03/11 10:47:37 UTC
ODMG and markDelete behaviour
Hi Armin, Hi all.
Well, with a little confusion, we believed that our bug of complex update
was not one. But it remains.
I'm suspecting a bug of OJB concerning the transcription of the
"markDelete" in SQL operations.
If I have time, I will try to assemble a demonstrative case of test with
Junit. For the moment, I give you the simplified case :
Consider A1 and B1 cross referenced objetcs, each one referring the other.
The process consists with create A2, and replace A1.
So, with ODMG, we wrote something like that :
1. retrieve A1, retrieve B1 with A1.getB()
2. instanciation and lock of A2
3. A2.setB(B1)
4. delete A1 (markDelete)
5. lock B1, B1.setA(null)
6. flush (assume it is required)
7. lock B1
8. B1.setA(A2)
9. commit
After commit, we observed that in database, B1 doesn't refers A2 !!
Now let's do it again (remember that B1 doesn't reference A2), let's create
A3.
After commit, B1 refers well A3.
We saw that the markDelete(A1) produces an update equivalent to B1.setA(null)
at commit without taking account of the last state of the object B1. All
occurs as if the markDelete(A1) considers the state of B1 at the beginning
of the transaction (that is linked to A1 so) and decide to unreference
A1 which have to be deleted. The evidence is that with no reference from B1
to A2 at start of a new run, B1 refers well A3. Surely because there is
nothing to unreference.
I specify that the model is obviously more complex than that, but I
preferred a simple case that a complex one. Only subtlety being a relation
1:N from B to A (in more) which makes it possible to archive the objects A
when they have to be not deleted (another transaction does that). So from B
to A there is a reference-descriptor and a collection-descriptor (using same
DB key field) and from A to B we have 2 reference-descriptors. I do not
believe there is a cause in that, but i give the information. There's more
than one flush too. Using : OJB1.0.4, DefaultCacheObjectImpl and Oracle 9i
and MS SQl server.
We searched everywhere : repository auto-update/auto-retrieve (all at none
as mandatory for ODMG), bad declarations of relations (foreign key checked),
tx settings (ordering/not, implicit locking/not), OJB settings. No way.
If someone experienced such a trouble , please tell us.
Thank you for any help.
Regards
Re: ODMG and markDelete behaviour
Posted by Armin Waibel <ar...@apache.org>.
Hi Bruno,
>
> I think the bug is due to the flush and markDelete.
>
you are right, the bug is indirectly caused by the
TransactionExt.flush() call.
In this case OJB reuse all registered object entries but doesn't clear
1:1, 1:n link history. Thus these operations will be called again on
next flush() or commit() call.
I open an issue in JIRA
http://issues.apache.org/jira/browse/OJB-103
The fix will be included in OJB 1.0.5.
You can patch 1.0.4 by modify
...odmg.ObjectEnvelope.java Line 162
if(reuse)
{
refreshObjectImage(wasInsert);
if(linkEntryList.size() > 0) linkEntryList.clear(); // patch
}
regards,
Armin
Armin Waibel wrote:
> Hi Bruno,
>
> Bruno CROS wrote:
>> Hi,
>>
>> well, if i do not flush, process can't work. We tried to avoid them, but
>> process seems to not (several circular references as i explained you a
>> few
>> days ago)
>>
>> I didn't get OJB test suite running (without any change of 1.0.4 binary
>> dist). the DB creation step crashes with an unknown CLOB type.What i'm
>> supposed to do to get it work ?
>>
>
> I recommend to use "fresh" OJB 1.0.4 release with default settings (in
> this case hsql was used). Then (on console) type:
>
> ant junit
>
> This will run the OJB test suite.
>
> Each test has a main method, so it's possible to invoke single test
> classes like apps. If your IDE supports JUnit configuration it's
> possible to invoke single test methods.
> Personally I do:
> 1. call 'ant prepare-testdb'
> This create the hsql database and prepare the OJB configuration files in
> db-ojb/ojb/target/test/ojb
> 2. When I invoke tests within my IDE I set the working directory to
> db-ojb/ojb/target/test/ojb
> Now you can run the OJB test-suite tests within your IDE.
>
> If this is correctly setup I try to run the tests against other DB's
> (e.g. I use maxDB):
> 1. Change the 'profile' property in db-ojb/build.properties
> 2. Change adjust the settings of the DB profile in db-ojb/profile
> Now you can run the test-suite against your own DB (ant junit) or you
> can prepare for testing with 'ant prepare-testdb' and call tests within
> your IDE.
> It could happen the torque report some errors (could not create tables)
> while setup the DB (e.g. BLOB, CLOB, VARBINARY issues).
>
>
>> Would you add flush into the test, please? (as the example) and may be
>> the
>> collection relation "allDetails" storing some details from shop (keep
>> existing 1:1 Detail relation). Key field is the same, no ?
>>
>> I think the bug is due to the flush and markDelete.
>>
>> Thanks for this work.
>>
>> i use implicit locking, ordering, and CacheDefaultImpl.
>>
>
> ok, I setup a similar test doing all calls you post in your first mail
> (step 1. to 9.). Now I can reproduce it. The problem seems that OJB
> doesn't recognize the B1.setA(A2) call.
> A workaround is to nullify the reference on move in A2 (3b.):
>
> 1. retrieve A1, retrieve B1 with A1.getB()
> 2. instanciation and lock of A2
> 3. A2.setB(B1)
> 3b. B1.setA(null)
> 4. delete A1 (markDelete)
> 5. lock B1, B1.setA(null)
> 6. flush (assume it is required)
> 7. lock B1
> 8. B1.setA(A2)
> 9. commit
>
> I will try to fix this for OJB 1.0.5.
>
> regards,
> Armin
>
>>
>> On 3/15/06, Armin Waibel <ar...@apache.org> wrote:
>>> Hi Bruno,
>>>
>>> I setup a similar test in
>>> CircularTest#testBidirectionalOneToOneMoveObject()
>>>
>>> http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?rev=386117&view=markup
>>>
>>>
>>> The test works like a charm.
>>>
>>> Compared with your post this test doesn't need flush() calls
>>>
>>>> 1. retrieve A1, retrieve B1 with A1.getB()
>>>> 2. instantiation and lock of A2
>>> 3. lock A1, B1 (depends on the configuration settings, implicit locking)
>>>> 4. A2.setB(B1)
>>> 5. B1.setA(null)
>>>> 6. delete A1 (markDelete)
>>>> 7. commit
>>> regards,
>>> Armin
>>>
>>> Bruno CROS wrote:
>>>> Hi Armin, Hi all.
>>>>
>>>> Well, with a little confusion, we believed that our bug of complex
>>> update
>>>> was not one. But it remains.
>>>>
>>>> I'm suspecting a bug of OJB concerning the transcription of the
>>>> "markDelete" in SQL operations.
>>>>
>>>> If I have time, I will try to assemble a demonstrative case of test
>>> with
>>>> Junit. For the moment, I give you the simplified case :
>>>>
>>>> Consider A1 and B1 cross referenced objetcs, each one referring the
>>> other.
>>>> The process consists with create A2, and replace A1.
>>>>
>>>> So, with ODMG, we wrote something like that :
>>>>
>>>> 1. retrieve A1, retrieve B1 with A1.getB()
>>>> 2. instanciation and lock of A2
>>>> 3. A2.setB(B1)
>>>> 4. delete A1 (markDelete)
>>>> 5. lock B1, B1.setA(null)
>>>> 6. flush (assume it is required)
>>>> 7. lock B1
>>>> 8. B1.setA(A2)
>>>> 9. commit
>>>>
>>>> After commit, we observed that in database, B1 doesn't refers A2 !!
>>>>
>>>> Now let's do it again (remember that B1 doesn't reference A2), let's
>>> create
>>>> A3.
>>>> After commit, B1 refers well A3.
>>>>
>>>> We saw that the markDelete(A1) produces an update equivalent to B1.setA
>>> (null)
>>>> at commit without taking account of the last state of the object B1.
>>>> All
>>>> occurs as if the markDelete(A1) considers the state of B1 at the
>>> beginning
>>>> of the transaction (that is linked to A1 so) and decide to unreference
>>>> A1 which have to be deleted. The evidence is that with no reference
>>>> from
>>> B1
>>>> to A2 at start of a new run, B1 refers well A3. Surely because there is
>>>> nothing to unreference.
>>>>
>>>> I specify that the model is obviously more complex than that, but I
>>>> preferred a simple case that a complex one. Only subtlety being a
>>> relation
>>>> 1:N from B to A (in more) which makes it possible to archive the
>>>> objects
>>> A
>>>> when they have to be not deleted (another transaction does that). So
>>> from B
>>>> to A there is a reference-descriptor and a collection-descriptor (using
>>> same
>>>> DB key field) and from A to B we have 2 reference-descriptors. I do not
>>>> believe there is a cause in that, but i give the information. There's
>>> more
>>>> than one flush too. Using : OJB1.0.4, DefaultCacheObjectImpl and Oracle
>>> 9i
>>>> and MS SQl server.
>>>>
>>>> We searched everywhere : repository auto-update/auto-retrieve (all at
>>> none
>>>> as mandatory for ODMG), bad declarations of relations (foreign key
>>> checked),
>>>> tx settings (ordering/not, implicit locking/not), OJB settings. No way.
>>>>
>>>> If someone experienced such a trouble , please tell us.
>>>>
>>>> Thank you for any help.
>>>>
>>>> Regards
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: ODMG and markDelete behaviour
Posted by Armin Waibel <ar...@apache.org>.
Hi Bruno,
Bruno CROS wrote:
> Hi,
>
> well, if i do not flush, process can't work. We tried to avoid them, but
> process seems to not (several circular references as i explained you a few
> days ago)
>
> I didn't get OJB test suite running (without any change of 1.0.4 binary
> dist). the DB creation step crashes with an unknown CLOB type.What i'm
> supposed to do to get it work ?
>
I recommend to use "fresh" OJB 1.0.4 release with default settings (in
this case hsql was used). Then (on console) type:
ant junit
This will run the OJB test suite.
Each test has a main method, so it's possible to invoke single test
classes like apps. If your IDE supports JUnit configuration it's
possible to invoke single test methods.
Personally I do:
1. call 'ant prepare-testdb'
This create the hsql database and prepare the OJB configuration files in
db-ojb/ojb/target/test/ojb
2. When I invoke tests within my IDE I set the working directory to
db-ojb/ojb/target/test/ojb
Now you can run the OJB test-suite tests within your IDE.
If this is correctly setup I try to run the tests against other DB's
(e.g. I use maxDB):
1. Change the 'profile' property in db-ojb/build.properties
2. Change adjust the settings of the DB profile in db-ojb/profile
Now you can run the test-suite against your own DB (ant junit) or you
can prepare for testing with 'ant prepare-testdb' and call tests within
your IDE.
It could happen the torque report some errors (could not create tables)
while setup the DB (e.g. BLOB, CLOB, VARBINARY issues).
> Would you add flush into the test, please? (as the example) and may be the
> collection relation "allDetails" storing some details from shop (keep
> existing 1:1 Detail relation). Key field is the same, no ?
>
> I think the bug is due to the flush and markDelete.
>
> Thanks for this work.
>
> i use implicit locking, ordering, and CacheDefaultImpl.
>
ok, I setup a similar test doing all calls you post in your first mail
(step 1. to 9.). Now I can reproduce it. The problem seems that OJB
doesn't recognize the B1.setA(A2) call.
A workaround is to nullify the reference on move in A2 (3b.):
1. retrieve A1, retrieve B1 with A1.getB()
2. instanciation and lock of A2
3. A2.setB(B1)
3b. B1.setA(null)
4. delete A1 (markDelete)
5. lock B1, B1.setA(null)
6. flush (assume it is required)
7. lock B1
8. B1.setA(A2)
9. commit
I will try to fix this for OJB 1.0.5.
regards,
Armin
>
> On 3/15/06, Armin Waibel <ar...@apache.org> wrote:
>> Hi Bruno,
>>
>> I setup a similar test in
>> CircularTest#testBidirectionalOneToOneMoveObject()
>>
>> http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?rev=386117&view=markup
>>
>> The test works like a charm.
>>
>> Compared with your post this test doesn't need flush() calls
>>
>>> 1. retrieve A1, retrieve B1 with A1.getB()
>>> 2. instantiation and lock of A2
>> 3. lock A1, B1 (depends on the configuration settings, implicit locking)
>>> 4. A2.setB(B1)
>> 5. B1.setA(null)
>>> 6. delete A1 (markDelete)
>>> 7. commit
>> regards,
>> Armin
>>
>> Bruno CROS wrote:
>>> Hi Armin, Hi all.
>>>
>>> Well, with a little confusion, we believed that our bug of complex
>> update
>>> was not one. But it remains.
>>>
>>> I'm suspecting a bug of OJB concerning the transcription of the
>>> "markDelete" in SQL operations.
>>>
>>> If I have time, I will try to assemble a demonstrative case of test
>> with
>>> Junit. For the moment, I give you the simplified case :
>>>
>>> Consider A1 and B1 cross referenced objetcs, each one referring the
>> other.
>>> The process consists with create A2, and replace A1.
>>>
>>> So, with ODMG, we wrote something like that :
>>>
>>> 1. retrieve A1, retrieve B1 with A1.getB()
>>> 2. instanciation and lock of A2
>>> 3. A2.setB(B1)
>>> 4. delete A1 (markDelete)
>>> 5. lock B1, B1.setA(null)
>>> 6. flush (assume it is required)
>>> 7. lock B1
>>> 8. B1.setA(A2)
>>> 9. commit
>>>
>>> After commit, we observed that in database, B1 doesn't refers A2 !!
>>>
>>> Now let's do it again (remember that B1 doesn't reference A2), let's
>> create
>>> A3.
>>> After commit, B1 refers well A3.
>>>
>>> We saw that the markDelete(A1) produces an update equivalent to B1.setA
>> (null)
>>> at commit without taking account of the last state of the object B1. All
>>> occurs as if the markDelete(A1) considers the state of B1 at the
>> beginning
>>> of the transaction (that is linked to A1 so) and decide to unreference
>>> A1 which have to be deleted. The evidence is that with no reference from
>> B1
>>> to A2 at start of a new run, B1 refers well A3. Surely because there is
>>> nothing to unreference.
>>>
>>> I specify that the model is obviously more complex than that, but I
>>> preferred a simple case that a complex one. Only subtlety being a
>> relation
>>> 1:N from B to A (in more) which makes it possible to archive the objects
>> A
>>> when they have to be not deleted (another transaction does that). So
>> from B
>>> to A there is a reference-descriptor and a collection-descriptor (using
>> same
>>> DB key field) and from A to B we have 2 reference-descriptors. I do not
>>> believe there is a cause in that, but i give the information. There's
>> more
>>> than one flush too. Using : OJB1.0.4, DefaultCacheObjectImpl and Oracle
>> 9i
>>> and MS SQl server.
>>>
>>> We searched everywhere : repository auto-update/auto-retrieve (all at
>> none
>>> as mandatory for ODMG), bad declarations of relations (foreign key
>> checked),
>>> tx settings (ordering/not, implicit locking/not), OJB settings. No way.
>>>
>>> If someone experienced such a trouble , please tell us.
>>>
>>> Thank you for any help.
>>>
>>> Regards
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: ODMG and markDelete behaviour
Posted by Bruno CROS <br...@gmail.com>.
Hi,
well, if i do not flush, process can't work. We tried to avoid them, but
process seems to not (several circular references as i explained you a few
days ago)
I didn't get OJB test suite running (without any change of 1.0.4 binary
dist). the DB creation step crashes with an unknown CLOB type.What i'm
supposed to do to get it work ?
Would you add flush into the test, please? (as the example) and may be the
collection relation "allDetails" storing some details from shop (keep
existing 1:1 Detail relation). Key field is the same, no ?
I think the bug is due to the flush and markDelete.
Thanks for this work.
i use implicit locking, ordering, and CacheDefaultImpl.
On 3/15/06, Armin Waibel <ar...@apache.org> wrote:
>
> Hi Bruno,
>
> I setup a similar test in
> CircularTest#testBidirectionalOneToOneMoveObject()
>
> http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?rev=386117&view=markup
>
> The test works like a charm.
>
> Compared with your post this test doesn't need flush() calls
>
> > 1. retrieve A1, retrieve B1 with A1.getB()
> > 2. instantiation and lock of A2
> 3. lock A1, B1 (depends on the configuration settings, implicit locking)
> > 4. A2.setB(B1)
> 5. B1.setA(null)
> > 6. delete A1 (markDelete)
> > 7. commit
>
> regards,
> Armin
>
> Bruno CROS wrote:
> > Hi Armin, Hi all.
> >
> > Well, with a little confusion, we believed that our bug of complex
> update
> > was not one. But it remains.
> >
> > I'm suspecting a bug of OJB concerning the transcription of the
> > "markDelete" in SQL operations.
> >
> > If I have time, I will try to assemble a demonstrative case of test
> with
> > Junit. For the moment, I give you the simplified case :
> >
> > Consider A1 and B1 cross referenced objetcs, each one referring the
> other.
> >
> > The process consists with create A2, and replace A1.
> >
> > So, with ODMG, we wrote something like that :
> >
> > 1. retrieve A1, retrieve B1 with A1.getB()
> > 2. instanciation and lock of A2
> > 3. A2.setB(B1)
> > 4. delete A1 (markDelete)
> > 5. lock B1, B1.setA(null)
> > 6. flush (assume it is required)
> > 7. lock B1
> > 8. B1.setA(A2)
> > 9. commit
> >
> > After commit, we observed that in database, B1 doesn't refers A2 !!
> >
> > Now let's do it again (remember that B1 doesn't reference A2), let's
> create
> > A3.
> > After commit, B1 refers well A3.
> >
> > We saw that the markDelete(A1) produces an update equivalent to B1.setA
> (null)
> > at commit without taking account of the last state of the object B1. All
> > occurs as if the markDelete(A1) considers the state of B1 at the
> beginning
> > of the transaction (that is linked to A1 so) and decide to unreference
> > A1 which have to be deleted. The evidence is that with no reference from
> B1
> > to A2 at start of a new run, B1 refers well A3. Surely because there is
> > nothing to unreference.
> >
> > I specify that the model is obviously more complex than that, but I
> > preferred a simple case that a complex one. Only subtlety being a
> relation
> > 1:N from B to A (in more) which makes it possible to archive the objects
> A
> > when they have to be not deleted (another transaction does that). So
> from B
> > to A there is a reference-descriptor and a collection-descriptor (using
> same
> > DB key field) and from A to B we have 2 reference-descriptors. I do not
> > believe there is a cause in that, but i give the information. There's
> more
> > than one flush too. Using : OJB1.0.4, DefaultCacheObjectImpl and Oracle
> 9i
> > and MS SQl server.
> >
> > We searched everywhere : repository auto-update/auto-retrieve (all at
> none
> > as mandatory for ODMG), bad declarations of relations (foreign key
> checked),
> > tx settings (ordering/not, implicit locking/not), OJB settings. No way.
> >
> > If someone experienced such a trouble , please tell us.
> >
> > Thank you for any help.
> >
> > Regards
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: ODMG and markDelete behaviour
Posted by Armin Waibel <ar...@apache.org>.
Bruno CROS wrote:
> I just see that there 's no "B1.set(A2)" in you proposition
>
> For me , the results is not a 1:1 cross reference.
>
You are right. Test is fixed in SVN.
Thanks!
regards,
Armin
> Regards
>
>
>
> On 3/15/06, Armin Waibel <ar...@apache.org> wrote:
>> Hi Bruno,
>>
>> I setup a similar test in
>> CircularTest#testBidirectionalOneToOneMoveObject()
>>
>> http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?rev=386117&view=markup
>>
>> The test works like a charm.
>>
>> Compared with your post this test doesn't need flush() calls
>>
>>> 1. retrieve A1, retrieve B1 with A1.getB()
>>> 2. instantiation and lock of A2
>> 3. lock A1, B1 (depends on the configuration settings, implicit locking)
>>> 4. A2.setB(B1)
>> 5. B1.setA(null)
>>> 6. delete A1 (markDelete)
>>> 7. commit
>> regards,
>> Armin
>>
>> Bruno CROS wrote:
>>> Hi Armin, Hi all.
>>>
>>> Well, with a little confusion, we believed that our bug of complex
>> update
>>> was not one. But it remains.
>>>
>>> I'm suspecting a bug of OJB concerning the transcription of the
>>> "markDelete" in SQL operations.
>>>
>>> If I have time, I will try to assemble a demonstrative case of test
>> with
>>> Junit. For the moment, I give you the simplified case :
>>>
>>> Consider A1 and B1 cross referenced objetcs, each one referring the
>> other.
>>> The process consists with create A2, and replace A1.
>>>
>>> So, with ODMG, we wrote something like that :
>>>
>>> 1. retrieve A1, retrieve B1 with A1.getB()
>>> 2. instanciation and lock of A2
>>> 3. A2.setB(B1)
>>> 4. delete A1 (markDelete)
>>> 5. lock B1, B1.setA(null)
>>> 6. flush (assume it is required)
>>> 7. lock B1
>>> 8. B1.setA(A2)
>>> 9. commit
>>>
>>> After commit, we observed that in database, B1 doesn't refers A2 !!
>>>
>>> Now let's do it again (remember that B1 doesn't reference A2), let's
>> create
>>> A3.
>>> After commit, B1 refers well A3.
>>>
>>> We saw that the markDelete(A1) produces an update equivalent to B1.setA
>> (null)
>>> at commit without taking account of the last state of the object B1. All
>>> occurs as if the markDelete(A1) considers the state of B1 at the
>> beginning
>>> of the transaction (that is linked to A1 so) and decide to unreference
>>> A1 which have to be deleted. The evidence is that with no reference from
>> B1
>>> to A2 at start of a new run, B1 refers well A3. Surely because there is
>>> nothing to unreference.
>>>
>>> I specify that the model is obviously more complex than that, but I
>>> preferred a simple case that a complex one. Only subtlety being a
>> relation
>>> 1:N from B to A (in more) which makes it possible to archive the objects
>> A
>>> when they have to be not deleted (another transaction does that). So
>> from B
>>> to A there is a reference-descriptor and a collection-descriptor (using
>> same
>>> DB key field) and from A to B we have 2 reference-descriptors. I do not
>>> believe there is a cause in that, but i give the information. There's
>> more
>>> than one flush too. Using : OJB1.0.4, DefaultCacheObjectImpl and Oracle
>> 9i
>>> and MS SQl server.
>>>
>>> We searched everywhere : repository auto-update/auto-retrieve (all at
>> none
>>> as mandatory for ODMG), bad declarations of relations (foreign key
>> checked),
>>> tx settings (ordering/not, implicit locking/not), OJB settings. No way.
>>>
>>> If someone experienced such a trouble , please tell us.
>>>
>>> Thank you for any help.
>>>
>>> Regards
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: ODMG and markDelete behaviour
Posted by Bruno CROS <br...@gmail.com>.
I just see that there 's no "B1.set(A2)" in you proposition
For me , the results is not a 1:1 cross reference.
Regards
On 3/15/06, Armin Waibel <ar...@apache.org> wrote:
>
> Hi Bruno,
>
> I setup a similar test in
> CircularTest#testBidirectionalOneToOneMoveObject()
>
> http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?rev=386117&view=markup
>
> The test works like a charm.
>
> Compared with your post this test doesn't need flush() calls
>
> > 1. retrieve A1, retrieve B1 with A1.getB()
> > 2. instantiation and lock of A2
> 3. lock A1, B1 (depends on the configuration settings, implicit locking)
> > 4. A2.setB(B1)
> 5. B1.setA(null)
> > 6. delete A1 (markDelete)
> > 7. commit
>
> regards,
> Armin
>
> Bruno CROS wrote:
> > Hi Armin, Hi all.
> >
> > Well, with a little confusion, we believed that our bug of complex
> update
> > was not one. But it remains.
> >
> > I'm suspecting a bug of OJB concerning the transcription of the
> > "markDelete" in SQL operations.
> >
> > If I have time, I will try to assemble a demonstrative case of test
> with
> > Junit. For the moment, I give you the simplified case :
> >
> > Consider A1 and B1 cross referenced objetcs, each one referring the
> other.
> >
> > The process consists with create A2, and replace A1.
> >
> > So, with ODMG, we wrote something like that :
> >
> > 1. retrieve A1, retrieve B1 with A1.getB()
> > 2. instanciation and lock of A2
> > 3. A2.setB(B1)
> > 4. delete A1 (markDelete)
> > 5. lock B1, B1.setA(null)
> > 6. flush (assume it is required)
> > 7. lock B1
> > 8. B1.setA(A2)
> > 9. commit
> >
> > After commit, we observed that in database, B1 doesn't refers A2 !!
> >
> > Now let's do it again (remember that B1 doesn't reference A2), let's
> create
> > A3.
> > After commit, B1 refers well A3.
> >
> > We saw that the markDelete(A1) produces an update equivalent to B1.setA
> (null)
> > at commit without taking account of the last state of the object B1. All
> > occurs as if the markDelete(A1) considers the state of B1 at the
> beginning
> > of the transaction (that is linked to A1 so) and decide to unreference
> > A1 which have to be deleted. The evidence is that with no reference from
> B1
> > to A2 at start of a new run, B1 refers well A3. Surely because there is
> > nothing to unreference.
> >
> > I specify that the model is obviously more complex than that, but I
> > preferred a simple case that a complex one. Only subtlety being a
> relation
> > 1:N from B to A (in more) which makes it possible to archive the objects
> A
> > when they have to be not deleted (another transaction does that). So
> from B
> > to A there is a reference-descriptor and a collection-descriptor (using
> same
> > DB key field) and from A to B we have 2 reference-descriptors. I do not
> > believe there is a cause in that, but i give the information. There's
> more
> > than one flush too. Using : OJB1.0.4, DefaultCacheObjectImpl and Oracle
> 9i
> > and MS SQl server.
> >
> > We searched everywhere : repository auto-update/auto-retrieve (all at
> none
> > as mandatory for ODMG), bad declarations of relations (foreign key
> checked),
> > tx settings (ordering/not, implicit locking/not), OJB settings. No way.
> >
> > If someone experienced such a trouble , please tell us.
> >
> > Thank you for any help.
> >
> > Regards
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: ODMG and markDelete behaviour
Posted by Armin Waibel <ar...@apache.org>.
Hi Bruno,
I setup a similar test in CircularTest#testBidirectionalOneToOneMoveObject()
http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?rev=386117&view=markup
The test works like a charm.
Compared with your post this test doesn't need flush() calls
> 1. retrieve A1, retrieve B1 with A1.getB()
> 2. instantiation and lock of A2
3. lock A1, B1 (depends on the configuration settings, implicit locking)
> 4. A2.setB(B1)
5. B1.setA(null)
> 6. delete A1 (markDelete)
> 7. commit
regards,
Armin
Bruno CROS wrote:
> Hi Armin, Hi all.
>
> Well, with a little confusion, we believed that our bug of complex update
> was not one. But it remains.
>
> I'm suspecting a bug of OJB concerning the transcription of the
> "markDelete" in SQL operations.
>
> If I have time, I will try to assemble a demonstrative case of test with
> Junit. For the moment, I give you the simplified case :
>
> Consider A1 and B1 cross referenced objetcs, each one referring the other.
>
> The process consists with create A2, and replace A1.
>
> So, with ODMG, we wrote something like that :
>
> 1. retrieve A1, retrieve B1 with A1.getB()
> 2. instanciation and lock of A2
> 3. A2.setB(B1)
> 4. delete A1 (markDelete)
> 5. lock B1, B1.setA(null)
> 6. flush (assume it is required)
> 7. lock B1
> 8. B1.setA(A2)
> 9. commit
>
> After commit, we observed that in database, B1 doesn't refers A2 !!
>
> Now let's do it again (remember that B1 doesn't reference A2), let's create
> A3.
> After commit, B1 refers well A3.
>
> We saw that the markDelete(A1) produces an update equivalent to B1.setA(null)
> at commit without taking account of the last state of the object B1. All
> occurs as if the markDelete(A1) considers the state of B1 at the beginning
> of the transaction (that is linked to A1 so) and decide to unreference
> A1 which have to be deleted. The evidence is that with no reference from B1
> to A2 at start of a new run, B1 refers well A3. Surely because there is
> nothing to unreference.
>
> I specify that the model is obviously more complex than that, but I
> preferred a simple case that a complex one. Only subtlety being a relation
> 1:N from B to A (in more) which makes it possible to archive the objects A
> when they have to be not deleted (another transaction does that). So from B
> to A there is a reference-descriptor and a collection-descriptor (using same
> DB key field) and from A to B we have 2 reference-descriptors. I do not
> believe there is a cause in that, but i give the information. There's more
> than one flush too. Using : OJB1.0.4, DefaultCacheObjectImpl and Oracle 9i
> and MS SQl server.
>
> We searched everywhere : repository auto-update/auto-retrieve (all at none
> as mandatory for ODMG), bad declarations of relations (foreign key checked),
> tx settings (ordering/not, implicit locking/not), OJB settings. No way.
>
> If someone experienced such a trouble , please tell us.
>
> Thank you for any help.
>
> Regards
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org