You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Jakob Braeuchi <jb...@gmx.ch> on 2004/02/02 19:14:26 UTC
build problem prepare-testdb hangs
hi all,
after getting the latest from repository i can no longer build a test-database
in hsqldb.
build prepare-testdb hangs :
....
[torque-data-sql] Using contextProperties file:
E:\Java_Work\_projects\db-ojb\build.properties
[torque-data-sql] Using classpath
[torque-data-sql] Generating to file
E:\Java_Work\_projects\db-ojb\target\test\sql\ojbtest-data.sql
[torque-data-sql] Parsing file: 'ojbtest-schema.xml'
[torque-data-sql] (transform.DTDResolver 128 ) Resolver: used
database.dtd from org.apache.torque.engine.database.transform package
[torque-data-sql] Resolver: used
E:\Java_Work\_projects\db-ojb\target\test\ojbtest-data.dtd
jakob
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Optimization when storing new objects
Posted by Armin Waibel <ar...@apache.org>.
Hi Guillaume,
Guillaume Nodet wrote:
> Armin,
>
> Thanks a lot for you commit. It works great and this
> reduced by a factor of 3 the time spent in storing
> my objects in database.
Nice to hear!
Hope there will be no negative side-effects ;-)
Thanks for your great suggestions.
regards,
Armin
>
> Regards,
> Guillaume Nodet
>
> -----Message d'origine-----
> De : Armin Waibel [mailto:arminw@apache.org]
> Envoye : vendredi 6 fevrier 2004 12:33
> A : OJB Developers List
> Objet : Re: Optimization when storing new objects
>
>
> Hi Guillaume,
>
> Guillaume Nodet wrote:
>
>>I'm not sure what you mean by 'null' pk fields.
>
>
> If one of the declared PK fields of the given object represents
> 'null' (non primitive field value null, primitive number field value 0)
> we know that the given object is new and we don't need further checks
> (e.g. we don't try to materialize this object).
>
> <snip PB upcoming fix, line 664>
> boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
> Identity oid = new Identity(obj, this, cld);
> if (!doInsert)
> {
> doInsert = objectCache.lookup(oid) == null
> && !serviceBrokerHelper().doesExist(cld, oid, obj);
> }
> </snip>
>
> regards,
> Armin
>
>
>>But i'm using the SequenceManagerHighLowImpl to be
>>database agnostic. So the pk fields are
>>generated when constructing the Identity object.
>>
>
>
>
>
>
>>Regards,
>>Guillaume
>>
>>-----Message d'origine-----
>>De : Armin Waibel [mailto:arminw@apache.org]
>>Envoye : jeudi 5 fevrier 2004 14:48
>>A : OJB Developers List
>>Objet : Re: Optimization when storing new objects
>>
>>
>>Hi,
>>
>>Guillaume Nodet wrote:
>>
>>
>>
>>>I do understand the problem.
>>>But i ran my program under quantify, and i indeed 70% of the
>>>time used to store my objects are used trying to materialize
>>>inexistant objects...
>>>
>>>In the store(Object obj) method of PersistentBrokerImpl, an
>>>Identity object is created, just before looking in cache or
>>>trying to materialize object. When this identity is created
>>>it may ask for a unique value to the serviceSequenceManager.
>>>In this case, the object is sure not to be in database.
>>>Could this information be brought back to the PersistentBroker
>>>so that it does not try to make a cache lookup and materialize ?
>>>
>>
>>
>>ah, now it's clear. I will try to "fix" this.
>>Think an additional helper method can check for 'null'
>>PK fields.
>>
>>regards,
>>Armin
>>
>>
>>
>>>Guillaume
>>>
>>>-----Message d'origine-----
>>>De : Armin Waibel [mailto:arminw@apache.org]
>>>Envoye : jeudi 5 fevrier 2004 11:30
>>>A : OJB Developers List
>>>Objet : Re: Optimization when storing new objects
>>>
>>>
>>>Hi Guillaume,
>>>
>>>Guillaume Nodet wrote:
>>>
>>>
>>>
>>>
>>>>When inserting new objects in the database, would it be possible to avoid
>>>>trying to materialize them ?
>>>>For example when storing an object in ojb, ojb first tries to materialize
>>>>it.
>>>>If this fails, ojb passes true in the 'insert' parameter to the storeToDb
>>>>method.
>>>>This parameter is given to the storeCollections method, but when
>>>
>>>collections
>>>
>>>
>>>
>>>>are 1-n
>>>>with cascade store on, the parameter is not given to the store method.
>>>
>>>
>>>Think this is because we don't know whether or not the reference objects
>>>needs 'insert' or 'update'.
>>>
>>>regards,
>>>Armin
>>>
>>>
>>>
>>>
>>>>Would it be possible to call the store(Object obj, Identity oid,
>>>>ClassDescriptor cld, boolean insert)
>>>>instead to avoid trying to materialize the object when we know that is
>>>
>>>does
>>>
>>>
>>>
>>>>not exists ?
>>>>
>>>>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-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-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
RE: Optimization when storing new objects
Posted by Guillaume Nodet <gu...@deliasystems.com>.
Armin,
Thanks a lot for you commit. It works great and this
reduced by a factor of 3 the time spent in storing
my objects in database.
Regards,
Guillaume Nodet
-----Message d'origine-----
De : Armin Waibel [mailto:arminw@apache.org]
Envoye : vendredi 6 fevrier 2004 12:33
A : OJB Developers List
Objet : Re: Optimization when storing new objects
Hi Guillaume,
Guillaume Nodet wrote:
> I'm not sure what you mean by 'null' pk fields.
If one of the declared PK fields of the given object represents
'null' (non primitive field value null, primitive number field value 0)
we know that the given object is new and we don't need further checks
(e.g. we don't try to materialize this object).
<snip PB upcoming fix, line 664>
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
Identity oid = new Identity(obj, this, cld);
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
&& !serviceBrokerHelper().doesExist(cld, oid, obj);
}
</snip>
regards,
Armin
> But i'm using the SequenceManagerHighLowImpl to be
> database agnostic. So the pk fields are
> generated when constructing the Identity object.
>
> Regards,
> Guillaume
>
> -----Message d'origine-----
> De : Armin Waibel [mailto:arminw@apache.org]
> Envoye : jeudi 5 fevrier 2004 14:48
> A : OJB Developers List
> Objet : Re: Optimization when storing new objects
>
>
> Hi,
>
> Guillaume Nodet wrote:
>
>
>>I do understand the problem.
>>But i ran my program under quantify, and i indeed 70% of the
>>time used to store my objects are used trying to materialize
>>inexistant objects...
>>
>>In the store(Object obj) method of PersistentBrokerImpl, an
>>Identity object is created, just before looking in cache or
>>trying to materialize object. When this identity is created
>>it may ask for a unique value to the serviceSequenceManager.
>>In this case, the object is sure not to be in database.
>>Could this information be brought back to the PersistentBroker
>>so that it does not try to make a cache lookup and materialize ?
>>
>
>
> ah, now it's clear. I will try to "fix" this.
> Think an additional helper method can check for 'null'
> PK fields.
>
> regards,
> Armin
>
>
>>Guillaume
>>
>>-----Message d'origine-----
>>De : Armin Waibel [mailto:arminw@apache.org]
>>Envoye : jeudi 5 fevrier 2004 11:30
>>A : OJB Developers List
>>Objet : Re: Optimization when storing new objects
>>
>>
>>Hi Guillaume,
>>
>>Guillaume Nodet wrote:
>>
>>
>>
>>>When inserting new objects in the database, would it be possible to avoid
>>>trying to materialize them ?
>>>For example when storing an object in ojb, ojb first tries to materialize
>>>it.
>>>If this fails, ojb passes true in the 'insert' parameter to the storeToDb
>>>method.
>>>This parameter is given to the storeCollections method, but when
>>
>>collections
>>
>>
>>>are 1-n
>>>with cascade store on, the parameter is not given to the store method.
>>
>>
>>Think this is because we don't know whether or not the reference objects
>>needs 'insert' or 'update'.
>>
>>regards,
>>Armin
>>
>>
>>
>>>Would it be possible to call the store(Object obj, Identity oid,
>>>ClassDescriptor cld, boolean insert)
>>>instead to avoid trying to materialize the object when we know that is
>>
>>does
>>
>>
>>>not exists ?
>>>
>>>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-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-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Optimization when storing new objects
Posted by Armin Waibel <ar...@apache.org>.
Hi Guillaume,
Guillaume Nodet wrote:
> I'm not sure what you mean by 'null' pk fields.
If one of the declared PK fields of the given object represents
'null' (non primitive field value null, primitive number field value 0)
we know that the given object is new and we don't need further checks
(e.g. we don't try to materialize this object).
<snip PB upcoming fix, line 664>
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
Identity oid = new Identity(obj, this, cld);
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
&& !serviceBrokerHelper().doesExist(cld, oid, obj);
}
</snip>
regards,
Armin
> But i'm using the SequenceManagerHighLowImpl to be
> database agnostic. So the pk fields are
> generated when constructing the Identity object.
>
> Regards,
> Guillaume
>
> -----Message d'origine-----
> De : Armin Waibel [mailto:arminw@apache.org]
> Envoye : jeudi 5 fevrier 2004 14:48
> A : OJB Developers List
> Objet : Re: Optimization when storing new objects
>
>
> Hi,
>
> Guillaume Nodet wrote:
>
>
>>I do understand the problem.
>>But i ran my program under quantify, and i indeed 70% of the
>>time used to store my objects are used trying to materialize
>>inexistant objects...
>>
>>In the store(Object obj) method of PersistentBrokerImpl, an
>>Identity object is created, just before looking in cache or
>>trying to materialize object. When this identity is created
>>it may ask for a unique value to the serviceSequenceManager.
>>In this case, the object is sure not to be in database.
>>Could this information be brought back to the PersistentBroker
>>so that it does not try to make a cache lookup and materialize ?
>>
>
>
> ah, now it's clear. I will try to "fix" this.
> Think an additional helper method can check for 'null'
> PK fields.
>
> regards,
> Armin
>
>
>>Guillaume
>>
>>-----Message d'origine-----
>>De : Armin Waibel [mailto:arminw@apache.org]
>>Envoye : jeudi 5 fevrier 2004 11:30
>>A : OJB Developers List
>>Objet : Re: Optimization when storing new objects
>>
>>
>>Hi Guillaume,
>>
>>Guillaume Nodet wrote:
>>
>>
>>
>>>When inserting new objects in the database, would it be possible to avoid
>>>trying to materialize them ?
>>>For example when storing an object in ojb, ojb first tries to materialize
>>>it.
>>>If this fails, ojb passes true in the 'insert' parameter to the storeToDb
>>>method.
>>>This parameter is given to the storeCollections method, but when
>>
>>collections
>>
>>
>>>are 1-n
>>>with cascade store on, the parameter is not given to the store method.
>>
>>
>>Think this is because we don't know whether or not the reference objects
>>needs 'insert' or 'update'.
>>
>>regards,
>>Armin
>>
>>
>>
>>>Would it be possible to call the store(Object obj, Identity oid,
>>>ClassDescriptor cld, boolean insert)
>>>instead to avoid trying to materialize the object when we know that is
>>
>>does
>>
>>
>>>not exists ?
>>>
>>>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-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
RE: Optimization when storing new objects
Posted by Guillaume Nodet <gu...@deliasystems.com>.
I'm not sure what you mean by 'null' pk fields.
But i'm using the SequenceManagerHighLowImpl to be
database agnostic. So the pk fields are
generated when constructing the Identity object.
Regards,
Guillaume
-----Message d'origine-----
De : Armin Waibel [mailto:arminw@apache.org]
Envoye : jeudi 5 fevrier 2004 14:48
A : OJB Developers List
Objet : Re: Optimization when storing new objects
Hi,
Guillaume Nodet wrote:
> I do understand the problem.
> But i ran my program under quantify, and i indeed 70% of the
> time used to store my objects are used trying to materialize
> inexistant objects...
>
> In the store(Object obj) method of PersistentBrokerImpl, an
> Identity object is created, just before looking in cache or
> trying to materialize object. When this identity is created
> it may ask for a unique value to the serviceSequenceManager.
> In this case, the object is sure not to be in database.
> Could this information be brought back to the PersistentBroker
> so that it does not try to make a cache lookup and materialize ?
>
ah, now it's clear. I will try to "fix" this.
Think an additional helper method can check for 'null'
PK fields.
regards,
Armin
> Guillaume
>
> -----Message d'origine-----
> De : Armin Waibel [mailto:arminw@apache.org]
> Envoye : jeudi 5 fevrier 2004 11:30
> A : OJB Developers List
> Objet : Re: Optimization when storing new objects
>
>
> Hi Guillaume,
>
> Guillaume Nodet wrote:
>
>
>>When inserting new objects in the database, would it be possible to avoid
>>trying to materialize them ?
>>For example when storing an object in ojb, ojb first tries to materialize
>>it.
>>If this fails, ojb passes true in the 'insert' parameter to the storeToDb
>>method.
>>This parameter is given to the storeCollections method, but when
>
> collections
>
>>are 1-n
>>with cascade store on, the parameter is not given to the store method.
>
>
> Think this is because we don't know whether or not the reference objects
> needs 'insert' or 'update'.
>
> regards,
> Armin
>
>
>>Would it be possible to call the store(Object obj, Identity oid,
>>ClassDescriptor cld, boolean insert)
>>instead to avoid trying to materialize the object when we know that is
>
> does
>
>>not exists ?
>>
>>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-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
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
RE: Bug in batch mode
Posted by Guillaume Nodet <gu...@deliasystems.com>.
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>.
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
Re: Bug in batch mode
Posted by Oleg Nitz <on...@ukr.net>.
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
Bug in batch mode
Posted by Guillaume Nodet <gu...@deliasystems.com>.
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
Re: Optimization when storing new objects
Posted by Armin Waibel <ar...@apache.org>.
Hi,
Guillaume Nodet wrote:
> I do understand the problem.
> But i ran my program under quantify, and i indeed 70% of the
> time used to store my objects are used trying to materialize
> inexistant objects...
>
> In the store(Object obj) method of PersistentBrokerImpl, an
> Identity object is created, just before looking in cache or
> trying to materialize object. When this identity is created
> it may ask for a unique value to the serviceSequenceManager.
> In this case, the object is sure not to be in database.
> Could this information be brought back to the PersistentBroker
> so that it does not try to make a cache lookup and materialize ?
>
ah, now it's clear. I will try to "fix" this.
Think an additional helper method can check for 'null'
PK fields.
regards,
Armin
> Guillaume
>
> -----Message d'origine-----
> De : Armin Waibel [mailto:arminw@apache.org]
> Envoye : jeudi 5 fevrier 2004 11:30
> A : OJB Developers List
> Objet : Re: Optimization when storing new objects
>
>
> Hi Guillaume,
>
> Guillaume Nodet wrote:
>
>
>>When inserting new objects in the database, would it be possible to avoid
>>trying to materialize them ?
>>For example when storing an object in ojb, ojb first tries to materialize
>>it.
>>If this fails, ojb passes true in the 'insert' parameter to the storeToDb
>>method.
>>This parameter is given to the storeCollections method, but when
>
> collections
>
>>are 1-n
>>with cascade store on, the parameter is not given to the store method.
>
>
> Think this is because we don't know whether or not the reference objects
> needs 'insert' or 'update'.
>
> regards,
> Armin
>
>
>>Would it be possible to call the store(Object obj, Identity oid,
>>ClassDescriptor cld, boolean insert)
>>instead to avoid trying to materialize the object when we know that is
>
> does
>
>>not exists ?
>>
>>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-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
RE: Optimization when storing new objects
Posted by Guillaume Nodet <gu...@deliasystems.com>.
I do understand the problem.
But i ran my program under quantify, and i indeed 70% of the
time used to store my objects are used trying to materialize
inexistant objects...
In the store(Object obj) method of PersistentBrokerImpl, an
Identity object is created, just before looking in cache or
trying to materialize object. When this identity is created
it may ask for a unique value to the serviceSequenceManager.
In this case, the object is sure not to be in database.
Could this information be brought back to the PersistentBroker
so that it does not try to make a cache lookup and materialize ?
Guillaume
-----Message d'origine-----
De : Armin Waibel [mailto:arminw@apache.org]
Envoye : jeudi 5 fevrier 2004 11:30
A : OJB Developers List
Objet : Re: Optimization when storing new objects
Hi Guillaume,
Guillaume Nodet wrote:
> When inserting new objects in the database, would it be possible to avoid
> trying to materialize them ?
> For example when storing an object in ojb, ojb first tries to materialize
> it.
> If this fails, ojb passes true in the 'insert' parameter to the storeToDb
> method.
> This parameter is given to the storeCollections method, but when
collections
> are 1-n
> with cascade store on, the parameter is not given to the store method.
Think this is because we don't know whether or not the reference objects
needs 'insert' or 'update'.
regards,
Armin
> Would it be possible to call the store(Object obj, Identity oid,
> ClassDescriptor cld, boolean insert)
> instead to avoid trying to materialize the object when we know that is
does
> not exists ?
>
> 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
Re: Optimization when storing new objects
Posted by Armin Waibel <ar...@apache.org>.
Hi Guillaume,
Guillaume Nodet wrote:
> When inserting new objects in the database, would it be possible to avoid
> trying to materialize them ?
> For example when storing an object in ojb, ojb first tries to materialize
> it.
> If this fails, ojb passes true in the 'insert' parameter to the storeToDb
> method.
> This parameter is given to the storeCollections method, but when collections
> are 1-n
> with cascade store on, the parameter is not given to the store method.
Think this is because we don't know whether or not the reference objects
needs 'insert' or 'update'.
regards,
Armin
> Would it be possible to call the store(Object obj, Identity oid,
> ClassDescriptor cld, boolean insert)
> instead to avoid trying to materialize the object when we know that is does
> not exists ?
>
> 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
Optimization when storing new objects
Posted by Guillaume Nodet <gu...@deliasystems.com>.
When inserting new objects in the database, would it be possible to avoid
trying to materialize them ?
For example when storing an object in ojb, ojb first tries to materialize
it.
If this fails, ojb passes true in the 'insert' parameter to the storeToDb
method.
This parameter is given to the storeCollections method, but when collections
are 1-n
with cascade store on, the parameter is not given to the store method.
Would it be possible to call the store(Object obj, Identity oid,
ClassDescriptor cld, boolean insert)
instead to avoid trying to materialize the object when we know that is does
not exists ?
Regards,
Guillaume
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: build problem prepare-testdb hangs
Posted by Jakob Braeuchi <jb...@gmx.ch>.
thanks !
jakob
Thomas Dudziak wrote:
> On Wed, 4 Feb 2004, Jakob Braeuchi wrote:
>
>
>>hi tom,
>>
>>after replacing ojbtest-data.dtd and ojbtest-data.xml with the previous
>>revisions prepare-testdb works ?
>
>
> I initially changed the dtd (and hence the xml file) because the datadtd
> target of torque returned a different dtd.
> Since both versions work (at least for me ;-), this dtd change is
> obviously not significant so we might as well return to the previous
> version - done.
> It is however strange that torque freezes for you, don't know what caused
> that ...
>
> Tom
>
>
> ---------------------------------------------------------------------
> 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
Re: build problem prepare-testdb hangs
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Wed, 4 Feb 2004, Jakob Braeuchi wrote:
> hi tom,
>
> after replacing ojbtest-data.dtd and ojbtest-data.xml with the previous
> revisions prepare-testdb works ?
I initially changed the dtd (and hence the xml file) because the datadtd
target of torque returned a different dtd.
Since both versions work (at least for me ;-), this dtd change is
obviously not significant so we might as well return to the previous
version - done.
It is however strange that torque freezes for you, don't know what caused
that ...
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: build problem prepare-testdb hangs
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi tom,
after replacing ojbtest-data.dtd and ojbtest-data.xml with the previous
revisions prepare-testdb works ?
jakob
Jakob Braeuchi wrote:
> hi tom,
>
> i'm using hsqldb on winxp.
>
> this is the output form buil -v prepare-testdb:
>
> ...
> Override ignored for property schemaDirectory
> Override ignored for property torque.output.dir
> Override ignored for property complexObjectModel
> Override ignored for property DataDumpControlTemplate
> Override ignored for property addIntakeRetrievable
> Override ignored for property targetPackage
> Override ignored for property deprecation
> Override ignored for property sameJavaName
> Override ignored for property src.dir
> Property ${databaseName} has not been set
> Override ignored for property SQLControlTemplate
> [ant] Entering E:\Java_Work\_projects\db-ojb\build-torque.xml...
> Build sequence for target `datasql' is [datasql]
> Complete build sequence is [datasql, sql-template, project-datadtd,
> main, ojb-model, datadump, project-sql2xml, doc, ins
> ert-sql, id-table-init-sql, project-datasql, compile, create-db-check,
> create-db, project-ojb-model, om-classpath, check
> -om-zip, om-zip, ojb-repository, om-template, project-doc,
> om-zip-worker, project-create-db, project-ojb-repository, sql
> -classpath, javadocs, om-zip-worker-delete, check-use-classpath,
> check-run-only-on-schema-change, om-check, om, project-
> datadump, sql-check, sql, project-insert-sql, project-om, datadtd,
> project-sql, jdbc, project-jdbc, sql2xml, ]
>
> datasql:
> [echo] +-----------------------------------------------+
> [echo] | |
> [echo] | Generating SQL from data XML ! |
> [echo] | Woo hoo! |
> [echo] | |
> [echo] +-----------------------------------------------+
> [torque-data-sql] Using contextProperties file:
> E:\Java_Work\_projects\db-ojb\build.properties
> [torque-data-sql] Using templatePath: E:\Java_Work\_projects\templates
> [torque-data-sql] Using classpath
> [torque-data-sql] Generating to file
> E:\Java_Work\_projects\db-ojb\target\test\sql\ojbtest-data.sql
> [torque-data-sql] Parsing file: 'ojbtest-schema.xml'
> [torque-data-sql] (transform.DTDResolver 128 ) Resolver:
> used database.dtd from org.apache.torque.engine.d
> atabase.transform package
> [torque-data-sql] Resolver: used
> E:\Java_Work\_projects\db-ojb\target\test\ojbtest-data.dtd
>
> here it hangs with 100% cpu !
>
> jakob
>
> Thomas Dudziak wrote:
>
>> On Mon, 2 Feb 2004, Jakob Braeuchi wrote:
>>
>>
>>> hi all,
>>>
>>> after getting the latest from repository i can no longer build a
>>> test-database in hsqldb.
>>>
>>> build prepare-testdb hangs :
>>>
>>> ....
>>> [torque-data-sql] Using contextProperties file:
>>> E:\Java_Work\_projects\db-ojb\build.properties
>>> [torque-data-sql] Using classpath
>>> [torque-data-sql] Generating to file
>>> E:\Java_Work\_projects\db-ojb\target\test\sql\ojbtest-data.sql
>>> [torque-data-sql] Parsing file: 'ojbtest-schema.xml'
>>> [torque-data-sql] (transform.DTDResolver 128 )
>>> Resolver: used database.dtd from
>>> org.apache.torque.engine.database.transform package
>>> [torque-data-sql] Resolver: used
>>> E:\Java_Work\_projects\db-ojb\target\test\ojbtest-data.dtd
>>
>>
>>
>> I had done some slight changes to the testdb setup: the schemas are
>> copied to the test directory prior to using torque on them and in this
>> step the @DATABASE_DEFAULT@ token is replaced by the test database
>> name. I
>> also changed the names of the targets invoked in the torque build file. I
>> did test the changes with hsqldb and mysql (with a clean build of ojb).
>>
>> Could you provide some more details (which database etc.) and perhaps an
>> output of ant invoked with -v or -debug ?
>>
>> Tom
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: build problem prepare-testdb hangs
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi tom,
i'm using hsqldb on winxp.
this is the output form buil -v prepare-testdb:
...
Override ignored for property schemaDirectory
Override ignored for property torque.output.dir
Override ignored for property complexObjectModel
Override ignored for property DataDumpControlTemplate
Override ignored for property addIntakeRetrievable
Override ignored for property targetPackage
Override ignored for property deprecation
Override ignored for property sameJavaName
Override ignored for property src.dir
Property ${databaseName} has not been set
Override ignored for property SQLControlTemplate
[ant] Entering E:\Java_Work\_projects\db-ojb\build-torque.xml...
Build sequence for target `datasql' is [datasql]
Complete build sequence is [datasql, sql-template, project-datadtd, main,
ojb-model, datadump, project-sql2xml, doc, ins
ert-sql, id-table-init-sql, project-datasql, compile, create-db-check,
create-db, project-ojb-model, om-classpath, check
-om-zip, om-zip, ojb-repository, om-template, project-doc, om-zip-worker,
project-create-db, project-ojb-repository, sql
-classpath, javadocs, om-zip-worker-delete, check-use-classpath,
check-run-only-on-schema-change, om-check, om, project-
datadump, sql-check, sql, project-insert-sql, project-om, datadtd, project-sql,
jdbc, project-jdbc, sql2xml, ]
datasql:
[echo] +-----------------------------------------------+
[echo] | |
[echo] | Generating SQL from data XML ! |
[echo] | Woo hoo! |
[echo] | |
[echo] +-----------------------------------------------+
[torque-data-sql] Using contextProperties file:
E:\Java_Work\_projects\db-ojb\build.properties
[torque-data-sql] Using templatePath: E:\Java_Work\_projects\templates
[torque-data-sql] Using classpath
[torque-data-sql] Generating to file
E:\Java_Work\_projects\db-ojb\target\test\sql\ojbtest-data.sql
[torque-data-sql] Parsing file: 'ojbtest-schema.xml'
[torque-data-sql] (transform.DTDResolver 128 ) Resolver: used
database.dtd from org.apache.torque.engine.d
atabase.transform package
[torque-data-sql] Resolver: used
E:\Java_Work\_projects\db-ojb\target\test\ojbtest-data.dtd
here it hangs with 100% cpu !
jakob
Thomas Dudziak wrote:
> On Mon, 2 Feb 2004, Jakob Braeuchi wrote:
>
>
>>hi all,
>>
>>after getting the latest from repository i can no longer build a test-database
>>in hsqldb.
>>
>>build prepare-testdb hangs :
>>
>>....
>>[torque-data-sql] Using contextProperties file:
>>E:\Java_Work\_projects\db-ojb\build.properties
>>[torque-data-sql] Using classpath
>>[torque-data-sql] Generating to file
>>E:\Java_Work\_projects\db-ojb\target\test\sql\ojbtest-data.sql
>>[torque-data-sql] Parsing file: 'ojbtest-schema.xml'
>>[torque-data-sql] (transform.DTDResolver 128 ) Resolver: used
>>database.dtd from org.apache.torque.engine.database.transform package
>>[torque-data-sql] Resolver: used
>>E:\Java_Work\_projects\db-ojb\target\test\ojbtest-data.dtd
>
>
> I had done some slight changes to the testdb setup: the schemas are
> copied to the test directory prior to using torque on them and in this
> step the @DATABASE_DEFAULT@ token is replaced by the test database name. I
> also changed the names of the targets invoked in the torque build file. I
> did test the changes with hsqldb and mysql (with a clean build of ojb).
>
> Could you provide some more details (which database etc.) and perhaps an
> output of ant invoked with -v or -debug ?
>
> Tom
>
>
> ---------------------------------------------------------------------
> 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
Re: build problem prepare-testdb hangs
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 2 Feb 2004, Jakob Braeuchi wrote:
> hi all,
>
> after getting the latest from repository i can no longer build a test-database
> in hsqldb.
>
> build prepare-testdb hangs :
>
> ....
> [torque-data-sql] Using contextProperties file:
> E:\Java_Work\_projects\db-ojb\build.properties
> [torque-data-sql] Using classpath
> [torque-data-sql] Generating to file
> E:\Java_Work\_projects\db-ojb\target\test\sql\ojbtest-data.sql
> [torque-data-sql] Parsing file: 'ojbtest-schema.xml'
> [torque-data-sql] (transform.DTDResolver 128 ) Resolver: used
> database.dtd from org.apache.torque.engine.database.transform package
> [torque-data-sql] Resolver: used
> E:\Java_Work\_projects\db-ojb\target\test\ojbtest-data.dtd
I had done some slight changes to the testdb setup: the schemas are
copied to the test directory prior to using torque on them and in this
step the @DATABASE_DEFAULT@ token is replaced by the test database name. I
also changed the names of the targets invoked in the torque build file. I
did test the changes with hsqldb and mysql (with a clean build of ojb).
Could you provide some more details (which database etc.) and perhaps an
output of ant invoked with -v or -debug ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org