Are my problems out of the design of ojb ? Do you want i to write a test case ?
Regads, Guillaume -----Message d'origine----- De : Guillaume Nodet [mailto:[EMAIL PROTECTED] Envoyé : vendredi 6 février 2004 09:58 À : OJB Developers List; [EMAIL PROTECTED] Objet : RE: Bug in batch mode Hi Oleg, I'm working with the lastest cvs version, and yes the problem occurs. The problem you solved few days ago was due to foreign keys. This one occurs when deleting an object and then storing it. When deleting the object, the delete statemtents are kept in memory and not send to database, dut to the batch connection. But when the a new copy is stored just after that, ojb tries to materialize it with a select statemtent on the primary key (which in my case is not computed by ojb nor database). As the delete statement has not been sent to database yet, the select statement returns a valid row. So the broker thinks the object is in database and performs an update on this row. When the update is sent to the batch connection, it sees that the same table has already been touched, so it sends the batch containing the delete statement. When the next batch is executed, the update statement is performed on a non valid row. (For my tests, i'm using Oracle, and the update statement did not return an error, but the error occured when inserting objects with foreign keys on it, but that's not the point). This is a workaround for another problem i want to expose right now: i'm using a strongly hierarchical object model. I mean that i have 36 different tables to store my objects, but only 9 of them are "main" objects that we use directly. Other tables contains sub-objects (objects that are in collections of "main" object or other "sub-objects") that should not be materialized by themselves. The main purpose of my project is to synchronize our data (which are not stored in a RDMS). We've got two operations that we performed thanks to ojb (which is a very remarkable product): * in the first one, we make an initialization of data. All data are retrieved from our data source and we store objects in an empty database. That's the first part on which we have performance problems (see my previous mail to Armin) * in the second one, we are in synchronization mode. We receive objects that have been changed from our data source and store an updated copy them with ojb. So here comes the problem. When i receive an updated copy of a "main" object. At first, i called the store method on the broker, giving it the new copy of my object. The problem is that ojb is not aware that "sub-objects" should be deleted because i'm not modifying an ojb-aware object, i use a completely new copy of the object. So the store method did not delete old sub-objects collections. That's the reason why i do a delete, immediately followed by a store. I think this may be a great problem for other ojb users. I apologize for this long mail, but i want my problems to be as clear as possible. Regards, Guillaume Nodet -----Message d'origine----- De : Oleg Nitz [mailto:[EMAIL PROTECTED] Envoyé : vendredi 6 février 2004 01:13 À : OJB Developers List Objet : Re: Bug in batch mode Hi Guillaume, Have you tried the CVS version? I think this bug was recently fixed both in HEAD and in the OJB_BRANCH_1_0 Regards, Oleg On Thursday 05 February 2004 18:16, Guillaume Nodet wrote: > Because of a problem i have using collections, > i can not directly use a store on my object > to save it in the database. I need to perform > first a delete and then a store (as ojb does not > delete old objects from collections, and that i > think is another bug...). > The problem arise when i want to use batch mode. > > Let's examine the following code: > broker.delete(a); > broker.store(a); > It should leads to the following sql statements: > DELETE FROM A WHERE ... > SELECT FROM A WHERE ... // materializing > INSERT INTO A > > The problem arise in batch mode: > * the delete statement is kept in memory > * the select is done and returns a row > * so an update is send to the database and fails > > Regards > > Guillaume > > > --------------------------------------------------------------------- > 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]
