Just to make certain that I understand this correctly (as I asked this very
question in a seperate thread and got the opposite answer):
If I map a m:n relationship letting OJB manage the association table
(documentation refers to this as non-decomposed m:n), can I use the
PersistenceBroker API and still be able to manage the inclusion of instances
in the collection?
The example I gave was a Customer and a Product. The Customer has a
collection of Products, the relation of which is maintained in say a
CUSTOMER_PRODUCT table. Because it is "non-decomposed", I do not create a
CustomerProduct class. Now in client code, I do:
Customer customer = // lookup customer
Product firstProduct = // lookup Product #1
Product secondProduct = // lookup Product #2
customer.getProducts().add( firstProduct );
customer.getProducts().add( secondProduct );
pb.store( customer );
Later, account receivable realizes they made a mistake, so:
Customer customer = // lookup customer
Product secondProduct = // lookup Product #2
Product thirdProduct = // lookup Product #3
customer.getProducts().remove( secondProduct );
customer.getProducts().add( thirdProduct );
pb.store( customer );
After this second section, what will be left in the CUSTOMER_PRODUCT table?
The comment below makes it seem like all three will be there. If the above
does not work (i.e., if all three rows are still present in the association
table) then it does not seem possible to use non-decomposed m:n mappings
with the PersistenceBroker as there would be no way for me to access the
association table to even clean it up manually, aside from direct DB
access).
|-----Original Message-----
|From: Thomas Phan [mailto:[EMAIL PROTECTED]
|Sent: Thursday, February 27, 2003 12:02 PM
|To: OJB Users List
|Subject: Re: long transactions
|
|
|> > With OL you have a version column for each row.
|> > Say you load an object with version=15.
|> > you send it to the client.
|> > The client works on it and posts the modified object
|back to the server.
|> > the server then update the database.
|> > With OL it checks if the version field in the instance
|still matches the
|> > version entry in the database row.
|> > In our case we will know that some other process
|updated the object if
|the
|> > version cloumn is now greater 15.
|> > The server will then signal a problem to the client.
|> >
|> > If the version still matches, the object is updated to
|the db and the
|> > version field is incremented, to inform other
|processes about the
|update.
|> >
|>
|> Right, write conflicts are detected with OL. But will
|there be an
|> efficient merge of the updated graph? Say only one of
|the graph's n
|> objects was modified. Is OJB's use of its cache going to
|compare the
|> before/after status of each graph object and perform a
|db update on only
|> the one truly changed object?
|>
|> Are we close to being a FAQ item?
|
|Consider the case written in the OJB FAQ page:
|
|Say you use the PB to query an object O that has a
|collection attribute col
|with five elements a,b,c,d,e. Next you delete Objects d
|and e from col and
|store O again with PersistenceBroker.store(O);
|
|PB will store the remaining objects a,b,c. But it will not
|delete d and e !
|If you then requery object O it will again contain a,b,c,d,e !!!
|
|The PB keeps no transactional state of the persistent
|Objects, thus it does
|not know that d and e have to be deleted. (as a side note:
|deletion of d and
|e could also be an error, as there might be references to
|them from other
|objects !!!)
|
|^^^
|
|Will OL keeps the transactional state?
|
|If I want to use PB, after posting the modified object,
|i.e. O with a, b, c,
|back to the server, what's the easliest way to make PL to
|delete d and e
|around the call to PersistenceBroker.store(O)? Should I
|query the existing
|O, and compare a, b, c, d, e with a, b, c before I call store()?
|
|Does deleting the existing O by its primary key, and
|inserting the modified
|O is the easliest approach?
|
|thanks
|
|
|-----------------------------------------------------------
|----------
|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]
