Armin and Oleg,
I attached to this mail three tests that fails under the current
cvs version. The repository-junit.xml is to append at the end of the
original file.
Same thing with the BatchModeTest.java. (These are stripped beacause the
mail was too big to go to the mailing list).
I added two classes to the repository (at the end), the associated java
files and three unit tests (at the end of the BatchModeTest.java).
The first one (testDeleteInsert) is the problem that occurs in batch mode.
The second one (testEquals) is a problem for which i found a workaround,
that is deleting the object prior to store it again.
The last one (testDelete) is the problem with the markedForDelete list in
PersistenceBrokerImpl.
Regards,
Guillaume
-----Message d'origine-----
De : Oleg Nitz [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 11 février 2004 00:17
À : OJB Users List
Objet : Re: Bug in batch mode
Hi Guillaume,
I am sorry for the delay.
On Tuesday 10 February 2004 09:36, Guillaume Nodet wrote:
> Are my problems out of the design of ojb ?
Look at the end of testBatchStatementsOrder() method in BatchModeTest.java
Isn't there the same situation that you describe?
You can see my recent bugfix that I mentioned in my previous message
in BatchConnection.java around the "_touched" field, it is used to force
execution of batch if INSERTs follows after DELETE and in other similar
cases.
> Do you want i to write a test case ?
That would be great.
Regards,
Oleg
> -----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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<class-descriptor
class="org.apache.ojb.broker.MainObject"
table="MAIN_OBJECT">
<field-descriptor
name="id"
column="ID"
jdbc-type="INTEGER"
primarykey="true"
autoincrement="false"/>
<field-descriptor
name="name"
column="NAME"
jdbc-type="VARCHAR"
/>
<collection-descriptor
name="subObjects"
element-class-ref="org.apache.ojb.broker.SubObject"
auto-update="true"
auto-retrieve="true"
auto-delete="true">
<inverse-foreignkey field-ref="mainid"/>
<orderby name="OJB_ID"/>
</collection-descriptor>
</class-descriptor>
<class-descriptor
class="org.apache.ojb.broker.SubObject"
table="SUB_OBJECT">
<field-descriptor
name="ojbId"
column="OJB_ID"
jdbc-type="INTEGER"
primarykey="true"
anonymous="true"
autoincrement="true" />
<field-descriptor
name="name"
column="NAME"
jdbc-type="VARCHAR" />
<field-descriptor
name="mainid"
column="OJB_MAIN_ID"
jdbc-type="INTEGER"
access="anonymous"/>
</class-descriptor>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
