Re: ODMG and markDelete behaviour

[Armin Waibel]

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=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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]