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 Armin Waibel <ar...@apache.org> on 2005/03/18 03:14:56 UTC
odmg-api refactoring status
Hi Folks,
after rack my brains, smashing my computers and short of sleep it seems
that the odmg-api refactoring nearly finished. I will add new test cases
and fix all known issues in odmg-api - except 1 failure (hope I can fix
it soon). Will check in this stuff tomorrow.
That's the good news, the bad is that I have to change the auto-xxx
settings of m:n relations (instead 'false' now 'none') and we have a
dramatic performance decrease (60%).
Here are the important notes:
- All m:n relation need auto-update/delete 'none'. Currently the setting
is changed internal - needs fix till release, update of test case mappings.
- The cascading delete behavior of the odmg-api is now adjustable in
OJB.properties file and at runtime using the
TransactionExt#setCascadeDelete method
- Now odmg-api can handle m:n relations
- The object state detection was improved. Now new object in references
will be found, needless update statements will be prevented, proxy
objects will not be materialized on commit call (except on delete).
regards,
Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: odmg-api refactoring status
Posted by Martin Kalén <mk...@apache.org>.
Armin Waibel wrote:
>>>> With Oracle9i, default cache and DBCP I get 1 failure in ODMG (which
>>>> I presume is your known issue?):
>>>>
>>>> testUpdateWhenExchangeObjectsInCollection
>>>> Failure expected:<...1> but was:<...2>
>
> this test should pass, did you an 'ant clean' call after get the
> sources from CVS?
Yes I did ant clean, but not between changing settings. I'll re-test and
dig some more now that I know you expect it to pass.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: odmg-api refactoring status
Posted by Armin Waibel <ar...@apache.org>.
Martin Kalén wrote:
> Hehe, then I *do* speak the query language if it's possible with pure
> SQL. I was not sure if some "magic" had to be applied to ensure ordering
> across platforms etc.
>
> I checked in your suggested update to the testcase and now I get a green
> light:
>
> [junit] Running org.apache.ojb.broker.AllTests
> [junit] Tests run: 620, Failures: 0, Errors: 0, Time elapsed: 186,829 s
> [junit] Running org.apache.ojb.odmg.AllTests
> [junit] Tests run: 152, Failures: 0, Errors: 0, Time elapsed: 27,578 s
> [junit] Running org.apache.ojb.soda.AllTests
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3,5 s
> [junit] Running org.apache.ojb.otm.AllTests
> [junit] Tests run: 79, Failures: 0, Errors: 0, Time elapsed: 24,765 s
>
> -Go Brian, release! :)
>
> (Doco/website updates can easily be pushed a day or a half after as
> discussed previously.)
>
ok, I'm convinced.
Go Brian, go ;-)
regards,
Armin
> Cheers,
> Martin
>
> ---------------------------------------------------------------------
> 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: odmg-api refactoring status
Posted by Martin Kalén <mk...@apache.org>.
Armin Waibel wrote:
>> Using P6Spy I see that Oracle does:
>> SELECT A0.GAT_ID,A0.NAME FROM COLLECTION_GATHERER A0 WHERE A0.GAT_ID =
>> '181' OR (A0.GAT_ID = '182')
>
> Did you tried with
>
> final String queryStr = "select gatherer from " + Gatherer.class.getName()
> + " where gatId=$1 or gatId=$2 order by gatId asc";
Hehe, then I *do* speak the query language if it's possible with pure
SQL. I was not sure if some "magic" had to be applied to ensure ordering
across platforms etc.
I checked in your suggested update to the testcase and now I get a green
light:
[junit] Running org.apache.ojb.broker.AllTests
[junit] Tests run: 620, Failures: 0, Errors: 0, Time elapsed: 186,829 s
[junit] Running org.apache.ojb.odmg.AllTests
[junit] Tests run: 152, Failures: 0, Errors: 0, Time elapsed: 27,578 s
[junit] Running org.apache.ojb.soda.AllTests
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3,5 s
[junit] Running org.apache.ojb.otm.AllTests
[junit] Tests run: 79, Failures: 0, Errors: 0, Time elapsed: 24,765 s
-Go Brian, release! :)
(Doco/website updates can easily be pushed a day or a half after as
discussed previously.)
Cheers,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: odmg-api refactoring status
Posted by Armin Waibel <ar...@apache.org>.
> Nope, but it's the test that is defunct probably not the code. I checked
> in an updated version of the test to clarify my point of failure.
>
> The two Gatherer objects are stored OK and then retrieved with this query:
>
> "select gatherer from " + Gatherer.class.getName() + " where gatId=$1 or
> gatId=$2";
>
> Using P6Spy I see that Oracle does:
> SELECT A0.GAT_ID,A0.NAME FROM COLLECTION_GATHERER A0 WHERE A0.GAT_ID =
> '181' OR (A0.GAT_ID = '182')
>
Did you tried with
final String queryStr = "select gatherer from " + Gatherer.class.getName()
+ " where gatId=$1 or gatId=$2 order by gatId asc";
The ID of the second one should be greater than the first one.
Armin
>
> There is no guarantee on the returned order of these items as long as
> there is no ORDER BY, GROUP BY or similar on the query. This testcase
> will not be reproducable as long as no order is guaranteed. (After doing
> some additional inserts or updates Oracle might decide to flip the two
> again, and it's got the right to do so.)
>
> I don't speak ODMG query language so if you could maybe fix the query?
>
> Previous failure was on Collection but that's just because no assert was
> made that "gat2" was in fact the second Gatherer. With my update to the
> testcase this is asserted and thus it fails earlier. I now get:
> junit.framework.ComparisonFailure: Wrong gatherer returned: fetchedGat
> should be first Gatherer
> Expected:
> testUpdateWhenExchangeObjectsInCollection1111178759937_Gatherer
> Actual:
> testUpdateWhenExchangeObjectsInCollection1111178759937_Gatherer2
>
> Regards,
> Martin
>
> ---------------------------------------------------------------------
> 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: odmg-api refactoring status
Posted by Martin Kalén <mk...@apache.org>.
Armin Waibel wrote:
> I forget to check in one class (MaterializationCache). Does it make a
> difference with the new version?
Nope, but it's the test that is defunct probably not the code. I checked
in an updated version of the test to clarify my point of failure.
The two Gatherer objects are stored OK and then retrieved with this query:
"select gatherer from " + Gatherer.class.getName() + " where gatId=$1 or
gatId=$2";
Using P6Spy I see that Oracle does:
SELECT A0.GAT_ID,A0.NAME FROM COLLECTION_GATHERER A0 WHERE A0.GAT_ID =
'181' OR (A0.GAT_ID = '182')
There is no guarantee on the returned order of these items as long as
there is no ORDER BY, GROUP BY or similar on the query. This testcase
will not be reproducable as long as no order is guaranteed. (After doing
some additional inserts or updates Oracle might decide to flip the two
again, and it's got the right to do so.)
I don't speak ODMG query language so if you could maybe fix the query?
Previous failure was on Collection but that's just because no assert was
made that "gat2" was in fact the second Gatherer. With my update to the
testcase this is asserted and thus it fails earlier. I now get:
junit.framework.ComparisonFailure: Wrong gatherer returned: fetchedGat
should be first Gatherer
Expected:
testUpdateWhenExchangeObjectsInCollection1111178759937_Gatherer
Actual:
testUpdateWhenExchangeObjectsInCollection1111178759937_Gatherer2
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: odmg-api refactoring status
Posted by Armin Waibel <ar...@apache.org>.
I forget to check in one class (MaterializationCache). Does it make a
difference with the new version?
Armin
Armin Waibel wrote:
> this test should pass, did you an 'ant clean' call after get the sources
> from CVS?
>
> Armin
>
> Martin Kalén wrote:
>
>> Martin Kalén wrote:
>>
>>>> With Oracle9i, default cache and DBCP I get 1 failure in ODMG (which
>>>> I presume is your known issue?):
>>>>
>>>> testUpdateWhenExchangeObjectsInCollection
>>>> Failure expected:<...1> but was:<...2>
>>>
>>>
>>>
>>> Err... no, I don't. This was with TLCache (default *setting*)... :)
>>
>>
>>
>> Same goes with ObjectCacheDefaultImpl though. Do you expect this Armin
>> or should I debug something?
>>
>> Regards,
>> Martin
>>
>> ---------------------------------------------------------------------
>> 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: odmg-api refactoring status
Posted by Armin Waibel <ar...@apache.org>.
this test should pass, did you an 'ant clean' call after get the sources
from CVS?
Armin
Martin Kalén wrote:
> Martin Kalén wrote:
>
>>> With Oracle9i, default cache and DBCP I get 1 failure in ODMG (which
>>> I presume is your known issue?):
>>>
>>> testUpdateWhenExchangeObjectsInCollection
>>> Failure expected:<...1> but was:<...2>
>>
>>
>> Err... no, I don't. This was with TLCache (default *setting*)... :)
>
>
> Same goes with ObjectCacheDefaultImpl though. Do you expect this Armin
> or should I debug something?
>
> Regards,
> Martin
>
> ---------------------------------------------------------------------
> 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: odmg-api refactoring status
Posted by Martin Kalén <mk...@apache.org>.
Martin Kalén wrote:
>> With Oracle9i, default cache and DBCP I get 1 failure in ODMG (which I
>> presume is your known issue?):
>>
>> testUpdateWhenExchangeObjectsInCollection
>> Failure expected:<...1> but was:<...2>
>
> Err... no, I don't. This was with TLCache (default *setting*)... :)
Same goes with ObjectCacheDefaultImpl though. Do you expect this Armin
or should I debug something?
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: odmg-api refactoring status
Posted by Martin Kalén <mk...@apache.org>.
Martin Kalén wrote:
> With Oracle9i, default cache and DBCP I get 1 failure in ODMG (which I
> presume is your known issue?):
>
> testUpdateWhenExchangeObjectsInCollection
> Failure expected:<...1> but was:<...2>
Err... no, I don't. This was with TLCache (default *setting*)... :)
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: odmg-api refactoring status
Posted by Martin Kalén <mk...@apache.org>.
Armin Waibel wrote:
> The code is in CVS now. Please test this new stuff against your own
> odmg-api test suite if possible.
With Oracle9i, default cache and DBCP I get 1 failure in ODMG (which I
presume is your known issue?):
testUpdateWhenExchangeObjectsInCollection
Failure expected:<...1> but was:<...2>
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: odmg-api refactoring status
Posted by Armin Waibel <ar...@apache.org>.
The code is in CVS now. Please test this new stuff against your own
odmg-api test suite if possible.
The documentation needs review (especially odmg-tutorial and the
repository guide). Now the odmg-api expect auto-update/delete="none" for
all reference/collection-descriptor (instead 'false' in old version). So
all odmg-auto-xxx text passages needs update. Any help on this is welcome.
All known issues are fixed, there is only one new failure when a
specific combination is used: proxy, TLCache, circular references and
object materialization outside a running tx. Then two different object
graphs of the circular object will be instantiated and OJB will be confused.
The performance of the refactored odmg-api decrease:
before after
jdbc 1 1
pb 1,12 1,16
odmg 1,72 2,1 -30%
otm 2,75 2,9
But keep in mind it's working now ;-)
I run the test suite against hsql and maxDB with "default cache" and
TLCache.
regards,
Armin
Armin Waibel wrote:
> Hi Folks,
>
> after rack my brains, smashing my computers and short of sleep it seems
> that the odmg-api refactoring nearly finished. I will add new test cases
> and fix all known issues in odmg-api - except 1 failure (hope I can fix
> it soon). Will check in this stuff tomorrow.
>
> That's the good news, the bad is that I have to change the auto-xxx
> settings of m:n relations (instead 'false' now 'none') and we have a
> dramatic performance decrease (60%).
>
> Here are the important notes:
>
> - All m:n relation need auto-update/delete 'none'. Currently the setting
> is changed internal - needs fix till release, update of test case mappings.
>
> - The cascading delete behavior of the odmg-api is now adjustable in
> OJB.properties file and at runtime using the
> TransactionExt#setCascadeDelete method
>
> - Now odmg-api can handle m:n relations
>
> - The object state detection was improved. Now new object in references
> will be found, needless update statements will be prevented, proxy
> objects will not be materialized on commit call (except on delete).
>
> regards,
> Armin
>
>
> ---------------------------------------------------------------------
> 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: odmg-api refactoring status
Posted by Martin Kalén <mk...@apache.org>.
Armin Waibel wrote:
> after rack my brains, smashing my computers and short of sleep it seems
> that the odmg-api refactoring nearly finished.
Go easy on yourself Admin, we want to keep you alive also after the
release! :)
> That's the good news, the bad is that I have to change the auto-xxx
> settings of m:n relations (instead 'false' now 'none') and we have a
> dramatic performance decrease (60%).
It is better to do it slow but right in the first place. Optimizations
can always be candidates for future maintenance release. As long as you
get the functionality together, the new relase will be more functionally
correct and that is the big improvement.
My 0.02SEK. ;)
> - The cascading delete behavior of the odmg-api is now adjustable in
> OJB.properties file and at runtime using the
> TransactionExt#setCascadeDelete method
Cool.
> - Now odmg-api can handle m:n relations
Great!
> - The object state detection was improved. Now new object in references
> will be found, needless update statements will be prevented, proxy
> objects will not be materialized on commit call (except on delete).
Really good that you finally found the materialization problem.
Cheers,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: odmg-api refactoring status
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi armin,
Armin Waibel schrieb:
> Hi Folks,
>
> after rack my brains, smashing my computers and short of sleep it seems
> that the odmg-api refactoring nearly finished. I will add new test cases
> and fix all known issues in odmg-api - except 1 failure (hope I can fix
> it soon). Will check in this stuff tomorrow.
great news !
thanks for the good work.
jakob
>
> That's the good news, the bad is that I have to change the auto-xxx
> settings of m:n relations (instead 'false' now 'none') and we have a
> dramatic performance decrease (60%).
>
> Here are the important notes:
>
> - All m:n relation need auto-update/delete 'none'. Currently the setting
> is changed internal - needs fix till release, update of test case mappings.
>
> - The cascading delete behavior of the odmg-api is now adjustable in
> OJB.properties file and at runtime using the
> TransactionExt#setCascadeDelete method
>
> - Now odmg-api can handle m:n relations
>
> - The object state detection was improved. Now new object in references
> will be found, needless update statements will be prevented, proxy
> objects will not be materialized on commit call (except on delete).
>
> regards,
> Armin
>
>
> ---------------------------------------------------------------------
> 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: odmg-api refactoring status
Posted by Armin Waibel <ar...@apache.org>.
Thomas Dudziak wrote:
> On Fri, 18 Mar 2005 03:14:56 +0100, Armin Waibel <ar...@apache.org> wrote:
>
>
>>after rack my brains, smashing my computers and short of sleep it seems
>>that the odmg-api refactoring nearly finished. I will add new test cases
>>and fix all known issues in odmg-api - except 1 failure (hope I can fix
>>it soon). Will check in this stuff tomorrow.
>>
>>That's the good news, the bad is that I have to change the auto-xxx
>>settings of m:n relations (instead 'false' now 'none') and we have a
>>dramatic performance decrease (60%).
>
>
> Any idea why ?
>
Think the object state detection (iterate 4 times all registered
objects, first to find new and deleted objects, second to handle cascade
delete/insert for all deleted/new objects, third when write to DB,
fourth to cleanup things) and the object field image build (copy of all
fields and reference to all referenced objects) will be costly.
Have some improvements in mind, will try today.
>
>>Here are the important notes:
>>
>>- All m:n relation need auto-update/delete 'none'. Currently the setting
>>is changed internal - needs fix till release, update of test case mappings.
>
>
> Could you explain why ? Wouldn't it be better if the ODMG Api ignores
> these settings and always uses the 'none' setting internally so that
> one can mix PB and ODMG ?
>
This is exactly the problem. ODMG use the PB-api and currently it's not
possible to change the auto-xxx settings at runtime (remember, I suggest
this feature long time ago, but couldn't find the time to re-implement
it after my harddisk crash). So if odmg "ignores" the settings and
handle all stuff by itself, the PB-api auto-xxx settings still active
and "corrupt" store operations.
regards,
Armin
>
>>- The cascading delete behavior of the odmg-api is now adjustable in
>>OJB.properties file and at runtime using the
>>TransactionExt#setCascadeDelete method
>>
>>- Now odmg-api can handle m:n relations
>
>
> Great news!
>
>
>>- The object state detection was improved. Now new object in references
>>will be found, needless update statements will be prevented, proxy
>>objects will not be materialized on commit call (except on delete).
>
>
> regards,
> 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: odmg-api refactoring status
Posted by Thomas Dudziak <to...@gmail.com>.
On Fri, 18 Mar 2005 03:14:56 +0100, Armin Waibel <ar...@apache.org> wrote:
> after rack my brains, smashing my computers and short of sleep it seems
> that the odmg-api refactoring nearly finished. I will add new test cases
> and fix all known issues in odmg-api - except 1 failure (hope I can fix
> it soon). Will check in this stuff tomorrow.
>
> That's the good news, the bad is that I have to change the auto-xxx
> settings of m:n relations (instead 'false' now 'none') and we have a
> dramatic performance decrease (60%).
Any idea why ?
> Here are the important notes:
>
> - All m:n relation need auto-update/delete 'none'. Currently the setting
> is changed internal - needs fix till release, update of test case mappings.
Could you explain why ? Wouldn't it be better if the ODMG Api ignores
these settings and always uses the 'none' setting internally so that
one can mix PB and ODMG ?
> - The cascading delete behavior of the odmg-api is now adjustable in
> OJB.properties file and at runtime using the
> TransactionExt#setCascadeDelete method
>
> - Now odmg-api can handle m:n relations
Great news!
> - The object state detection was improved. Now new object in references
> will be found, needless update statements will be prevented, proxy
> objects will not be materialized on commit call (except on delete).
regards,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org