hmm, seems to be a similar problem. ODMG implementaion does not recognize the changed collection.
It's currently not solved. Test cases for the problem exist.
regards, Armin
R�mi Bars wrote:
hi all,
is this bug resolved?
i have the same bug in my collection when i add a new object my collection is fine updated, when i remove an object my collection is not updated....
Thank
Remi
----- Original Message ----- From: "Armin Waibel" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Friday, January 09, 2004 7:15 PM
Subject: Re: ODMG Update Collection Problem
Hi Ralf,
I write some more tests and review my old ones. Now only one test fails. It's the one when exchange collection objects. You can find test case in test suite, it's called ...odmg.CollectionsTest
Think it's a bug in OJB. The main object isn't get dirty when exchange the collection objects. See ...odmg.ObjectEnvelope line 317
regards, Armin
Ralf Geiger wrote:
Hi Armin,
no I've never tried another OJB-Version.
BTW I have another weird ODMG-API behavior: I told you that the update of automatic M:N - Mapping works fine... this
is
not true at all :( Following case: Object A holds a Collection of B-Objects and the other way around. So lets say: a1{b1}, b1{a1, a2} If you update like this: a1{b1} --> a1{b1, b2, b3} it works good with
the
usual ODMG transaction:
// newCollectionOfB {b1,b2,b3} tx.begin(); tx.lock(a1, ..WRITE) a1.setColOfB( newCollectionOfB ) tx.commit();
BUT funny is, that it works in this case only if there is more than one B-Object in the newCollectionOfB-Vector so if you want to do it like this: a1{b1} --> a1{b2} it won't work ! It will only work if you edit a1 outside the transaction and then txe.markDirty(a1}
or you can do it like this: :) a1{b1} --> a1{b2,b3} --> a1{b2}
So everytime you want to update the collection and the amount of
residing
B-Objects is the same it won't work with the tx.begin()...
lock()...commit()
... at least for me... I really don't know what I am doing wrong but I am running into weird problems all the time :(
regards,
Ralf
----- Original Message ----- From: "Armin Waibel" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Friday, January 09, 2004 2:24 PM
Subject: Re: ODMG Update Collection Problem
Hi Ralf,
I can reproduce your problem and checked in a test case. I think you are right in expecting that OJB should do that job. But I'm not sure (not an ODMG expert). Did your test pass with a previous version of OJB?
regards, Armin
Ralf Geiger wrote:
----- Original Message ----- From: "Armin Waibel" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Friday, January 09, 2004 11:31 AM
Subject: Re: ODMG Update Collection Problem
Ralf Geiger wrote:
...
So now the Problem is updating the Collection of B-Objects Lets say a1 has already 2 B-Objects within the collection (b1 and
b2):
Now I want to update the Collection and put the Objects (b3 and b4)
into
it - b3 and b4 are already existing in the DB just belong to a2.
The situation: a1{b1,b2}, a2{b3,b4} ---> a1{b3,b4}, a2{}, (b1 and b2 have null
references to any A-Object)
Do you lookup a1, a2 via PB-api too? If so, do you lock them before starting your modification?
Yeah, every Object I have has been loaded via PB-API.
My Applicationflow looks like this (web-application using Struts,
running in
Tomcat): 1. Action: using PB-API to get all A-Objects and put them into
Session-Scope
2. JSP: Show all A-Objects and referenced Bs.. just to see which Bs
are
pointing to which a. 3. User Interaction: Edit a1 4. EditAction: using PB-API to get all possible B-Objects so that the
User
can define which B-Objects he wants. 5. JSP: Show a1 and a List of B-Objects where he can choose... Let's
say
he
chose the b3 and b4 6. SaveAction: I get the Object a1 (toBeSaved), the b3 and b4 from
the
DB
(PB-API) (could have got it from the session-scope bean as well ) 7. Now I begin the transaction and lock the toBeSaved-Object... 8. make the changes and commit..
that's all..
hmm, can you try to do a ((TransactionExt) tx).markDirty(a1); ((TransactionExt) tx).markDirty(a2); // if was modified too
before do the commit.
regards, Armin
No, there is no change. The only way I can get it to work .. (at least see any change in the
db)
is
to loop all the B-Objects and set the references by hand. But I think
ODMG
should do the job.
Does 1:N work for you ? Could you post what Collection you use and how
you
update it ?
Thanks,
Ralf
regards,
Ralf
If I am not mistaken the steps OJB takes should look like this:
1. Delete the references of b1 (aid=null and refToA=null) and b2
which
are pointing to a1
2. Update the references of b3 and b4 so that they point to a1. 3. Update the Collection of a2 because b3 and b4 are not in the
collection of a2 anymore.
4 Update the Collection of a1: delete the references to b1 and b2
and
fill the collection with b3 and b4.
commit;
I tried several Collections (java.util.Vector, ManageableVector,
ManageableArrayList, DListImpl)
but nothing works. basically it for me it looks like this:
tx.begin() // Get the Collection of new Bs with
PersistenceBroker.getCollectionByQuery(B.class, crit) so I get this Collection: newColOfB{b3,b4}
// Get the Collection of a1: ManageableArrayList list = a1.getColOfB();
// now update the list: list.retainAll( newColOfB );
tx.commit();
But nothing has been updated in the DB..
What is it ?? Can somebody please point out how to solve this
problem
?
I really lost my nerves. Do I really have to update all references by myselfe ??
Or am I just too stupid ? It works fine with m:n relationships..
just
setting the new collection..
---------------------------------------------------------------------Thanks for your help,
Ralf Geiger
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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
