Re: ODMG and markDelete behaviour
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 [EMAIL PROTECTED] 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=386117view=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
Re: ODMG and markDelete behaviour
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 [EMAIL PROTECTED] 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=386117view=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,
Re: ODMG and markDelete behaviour
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=386117view=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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ODMG and markDelete behaviour
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 [EMAIL PROTECTED] 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=386117view=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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
