You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Guillaume Nodet <gu...@deliasystems.com> on 2004/02/10 10:36:51 UTC
RE: Bug in batch mode
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:guillaume.nodet@deliasystems.com]
Envoyé : vendredi 6 février 2004 09:58
À : OJB Developers List; on@ukr.net
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:on@ukr.net]
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: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RE: Bug in batch mode
Posted by Guillaume Nodet <gu...@deliasystems.com>.
Thanks, Oleg.
The commit you've done works great !
Regards,
Guillaume
> -----Message d'origine-----
> De : Oleg Nitz [mailto:on@ukr.net]
> Envoyé : lundi 16 février 2004 01:38
> À : OJB Users List
> Objet : Re: Bug in batch mode
>
>
> Hi Armin and Guillaume,
>
> Thank you very much for the test, which made easy to understand
> what happends.
> That was not really the bug in batch mode, but rather the feature
> in PB API,
> which I never liked: the same method store() is used for two operations,
> INSERT and UPDATE, and in the case of batch mode additional
> SELECT may not
> give a correct choice, namely if the object has been deleted, but
> the batch
> hasn't been executed yet. I've made the algorithm of choice of INSERT or
> DELETE a bit more clever and that solved the problem.
> I've committed the fix to CVS HEAD. Should I apply the fix to the
> branch-1.0?
>
> Regards,
> Oleg
>
> On Friday 13 February 2004 19:00, Armin Waibel wrote:
> > Hi Guillaume,
> >
> > ok, I get all your files to run your test.
> >
> > Have to make some modifications:
> >
> > - In metadata declaration of SubObject field 'mainid' you set access to
> > anonymous, this is not recommended here. Anonymous fields can only safe
> > used in conjunction with 1:1 references (The docs are not clear here,
> > but AFAIK Brian is working on an update).
> >
> > - In metadata declaration of SubObject field 'id' you declare an
> > attribute anonymous="true", such an attribute does not exist (AFAIK).
> >
> >
> > *testDeleteInsert()*
> > Seems to be a bug in batch handling. Without batch mode enabled test
> > pass, with enabled batch mode test fails.
> >
> >
> >
> > *testEquals()*
> > When I delete the object before storing the new instance with same PK
> > test pass
> >
> > broker.beginTransaction();
> > broker.store(main1);
> > // delete object before add new instance with same PK
> > broker.delete(main1);
> > broker.store(main2);
> > broker.commitTransaction();
> >
> >
> >
> > *testDelete()*
> > test pass.
> >
> > You can find the TestCase in test suite (CVS HEAD) called
> > ...broker.BatchModeTest. Please review my changes.
> >
> > regards,
> > Armin
> >
> > Guillaume Nodet wrote:
> > > I'm splitting it because i have problems when attaching a zip file.
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Bug in batch mode
Posted by Oleg Nitz <on...@ukr.net>.
Hi Armin and Guillaume,
Thank you very much for the test, which made easy to understand what happends.
That was not really the bug in batch mode, but rather the feature in PB API,
which I never liked: the same method store() is used for two operations,
INSERT and UPDATE, and in the case of batch mode additional SELECT may not
give a correct choice, namely if the object has been deleted, but the batch
hasn't been executed yet. I've made the algorithm of choice of INSERT or
DELETE a bit more clever and that solved the problem.
I've committed the fix to CVS HEAD. Should I apply the fix to the branch-1.0?
Regards,
Oleg
On Friday 13 February 2004 19:00, Armin Waibel wrote:
> Hi Guillaume,
>
> ok, I get all your files to run your test.
>
> Have to make some modifications:
>
> - In metadata declaration of SubObject field 'mainid' you set access to
> anonymous, this is not recommended here. Anonymous fields can only safe
> used in conjunction with 1:1 references (The docs are not clear here,
> but AFAIK Brian is working on an update).
>
> - In metadata declaration of SubObject field 'id' you declare an
> attribute anonymous="true", such an attribute does not exist (AFAIK).
>
>
> *testDeleteInsert()*
> Seems to be a bug in batch handling. Without batch mode enabled test
> pass, with enabled batch mode test fails.
>
>
>
> *testEquals()*
> When I delete the object before storing the new instance with same PK
> test pass
>
> broker.beginTransaction();
> broker.store(main1);
> // delete object before add new instance with same PK
> broker.delete(main1);
> broker.store(main2);
> broker.commitTransaction();
>
>
>
> *testDelete()*
> test pass.
>
> You can find the TestCase in test suite (CVS HEAD) called
> ...broker.BatchModeTest. Please review my changes.
>
> regards,
> Armin
>
> Guillaume Nodet wrote:
> > I'm splitting it because i have problems when attaching a zip file.
> >
> >
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RE: Bug in batch mode
Posted by Guillaume Nodet <gu...@deliasystems.com>.
Thanks a lot !
>
> - In metadata declaration of SubObject field 'mainid' you set access to
> anonymous, this is not recommended here. Anonymous fields can only safe
> used in conjunction with 1:1 references (The docs are not clear here,
> but AFAIK Brian is working on an update).
>
> - In metadata declaration of SubObject field 'id' you declare an
> attribute anonymous="true", such an attribute does not exist (AFAIK).
>
Sorry for the mistake, i wanted to type access="anonymous".
It may be where my problems come from. I actually use anonymous fields
the primary key and foreign key for the SubObject class.
This is necessary because i do not control the object model and as these
objects are stored in collections in the Main object, they do not have
primary keys and foreign keys fields. What could be the drawbacks of using
anonymous primary keys and/or foreign keys ?
>
> *testDeleteInsert()*
> Seems to be a bug in batch handling. Without batch mode enabled test
> pass, with enabled batch mode test fails.
>
I think Oleg has solved it by now. I'll try it asap.
>
>
> *testEquals()*
> When I delete the object before storing the new instance with same PK
> test pass
>
> broker.beginTransaction();
> broker.store(main1);
> // delete object before add new instance with same PK
> broker.delete(main1);
> broker.store(main2);
> broker.commitTransaction();
>
I have the same workaround, but the question is why must one delete
the object before storing it ? (I do understand why this does not work,
because i found the same workaround, but is this a bug or by-design).
>
>
> *testDelete()*
> test pass.
>
This is the problem you solved some days ago with the markedForDelete list,
so it should pass now.
Regards,
Guillaume
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Bug in batch mode
Posted by Armin Waibel <ar...@apache.org>.
Hi Guillaume,
ok, I get all your files to run your test.
Have to make some modifications:
- In metadata declaration of SubObject field 'mainid' you set access to
anonymous, this is not recommended here. Anonymous fields can only safe
used in conjunction with 1:1 references (The docs are not clear here,
but AFAIK Brian is working on an update).
- In metadata declaration of SubObject field 'id' you declare an
attribute anonymous="true", such an attribute does not exist (AFAIK).
*testDeleteInsert()*
Seems to be a bug in batch handling. Without batch mode enabled test
pass, with enabled batch mode test fails.
*testEquals()*
When I delete the object before storing the new instance with same PK
test pass
broker.beginTransaction();
broker.store(main1);
// delete object before add new instance with same PK
broker.delete(main1);
broker.store(main2);
broker.commitTransaction();
*testDelete()*
test pass.
You can find the TestCase in test suite (CVS HEAD) called
...broker.BatchModeTest. Please review my changes.
regards,
Armin
Guillaume Nodet wrote:
> I'm splitting it because i have problems when attaching a zip file.
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RE: Bug in batch mode
Posted by Guillaume Nodet <gu...@deliasystems.com>.
I'm splitting it because i have problems when attaching a zip file.
Re: Bug in batch mode
Posted by Armin Waibel <ar...@apache.org>.
Hi Guillaume,
Guillaume Nodet wrote:
> 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.
I can't find your junit tests (only the repository file is attached),
could you send me these files?
regards,
Armin
> 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:on@ukr.net]
> 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:guillaume.nodet@deliasystems.com]
>>Envoyé : vendredi 6 février 2004 09:58
>>À : OJB Developers List; on@ukr.net
>>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:on@ukr.net]
>>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: ojb-dev-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
> ------------------------------------------------------------------------
>
>
>
> <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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RE: Bug in batch mode
Posted by Guillaume Nodet <gu...@deliasystems.com>.
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:on@ukr.net]
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:guillaume.nodet@deliasystems.com]
> Envoyé : vendredi 6 février 2004 09:58
> À : OJB Developers List; on@ukr.net
> 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:on@ukr.net]
> 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: ojb-dev-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-dev-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Bug in batch mode
Posted by Oleg Nitz <on...@ukr.net>.
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:guillaume.nodet@deliasystems.com]
> Envoyé : vendredi 6 février 2004 09:58
> À : OJB Developers List; on@ukr.net
> 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:on@ukr.net]
> 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: ojb-dev-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-dev-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org