Re: Simple performance improvement Re: m:n relations mapping...
hi andy, oliver,
the patch is checked in.
olli please have a look at the method _storeCollections_ when time
permits, i think it needs refactoring.
jakob
Andy Malakov wrote:
Thanks.
In my case eliminating extra SELECT and DELETE for MtoNImplementor (as described below) made batch inserts 5 times faster.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2003 5:06 AM
Subject: RE: Simple performance improvement Re: m:n relations mapping...
Hello Andy,
I will have a look at it when I have time.
Please post messages like this to the OJB
users' or developers' list.
Thank you,
Olli
-Original Message-
From: Andy Malakov [mailto:[EMAIL PROTECTED]
Sent: Friday, October 31, 2003 9:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple performance improvement Re: m:n relations mapping...
Excellent.
Now how about going one step further and eliminating extra SELECT ? :-)))
We do not need to retrieve link table entries in case of new objects.
Class: org.apache.ojb.broker.core.PersistenceBrokerImpl:
Method: storeCollections(Object obj, Vector vecCds, boolean insert)
Line: 789
Now:
...
if (cds.isMtoNRelation())
{
currentMtoNKeys = getMtoNImplementor(cds, obj);
// delete unused m:n implementors
if (!insert)
{
deleteMtoNImplementor(cds, obj, (Collection)col, currentMtoNKeys);
}
}
Better:
...
if (cds.isMtoNRelation())
{
if (insert) {
currentMtoNKeys = java.util.Collections.EMPTY_LIST; // assume no
link table entries exist for new objects
} else {
currentMtoNKeys = getMtoNImplementor(cds, obj);
// delete unused m:n implementors
deleteMtoNImplementor (cds, obj, (Collection) col,
currentMtoNKeys);
}
}
I tested it with P6SPY - the above fix makes extra SELECTs disappear.
This two fixes make batch inserts of complex object work faster :-)
Thanks a lot for you product,
Andy
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 31, 2003 4:41 AM
Subject: RE: Simple performance improvement Re: m:n relations mapping...
Hello,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
I am uncertain whether we should fix it because it does
mean a (very minor) change of behaviour. I tend to 'yes'.
I have just committed a fix.
Olli
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple performance improvement Re: m:n relations mapping...
Thanks.
In my case eliminating extra SELECT and DELETE for MtoNImplementor (as described
below) made batch inserts 5 times faster.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2003 5:06 AM
Subject: RE: Simple performance improvement Re: m:n relations mapping...
> Hello Andy,
>
> I will have a look at it when I have time.
>
> Please post messages like this to the OJB
> users' or developers' list.
>
> Thank you,
> Olli
>
> -Original Message-
> From: Andy Malakov [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 31, 2003 9:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Simple performance improvement Re: m:n relations mapping...
>
>
> Excellent.
>
> Now how about going one step further and eliminating extra SELECT ? :-)))
>
> We do not need to retrieve link table entries in case of new objects.
>
> Class: org.apache.ojb.broker.core.PersistenceBrokerImpl:
> Method: storeCollections(Object obj, Vector vecCds, boolean insert)
> Line: 789
>
> Now:
> ...
> if (cds.isMtoNRelation())
> {
> currentMtoNKeys = getMtoNImplementor(cds, obj);
> // delete unused m:n implementors
> if (!insert)
> {
> deleteMtoNImplementor(cds, obj, (Collection)col, currentMtoNKeys);
> }
> }
>
> Better:
>
> ...
> if (cds.isMtoNRelation())
> {
> if (insert) {
> currentMtoNKeys = java.util.Collections.EMPTY_LIST; // assume no
> link table entries exist for new objects
> } else {
> currentMtoNKeys = getMtoNImplementor(cds, obj);
> // delete unused m:n implementors
> deleteMtoNImplementor (cds, obj, (Collection) col,
> currentMtoNKeys);
> }
> }
>
>
>
> I tested it with P6SPY - the above fix makes extra SELECTs disappear.
> This two fixes make batch inserts of complex object work faster :-)
>
> Thanks a lot for you product,
> Andy
>
>
>
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, October 31, 2003 4:41 AM
> Subject: RE: Simple performance improvement Re: m:n relations mapping...
>
>
> > Hello,
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > >
> > > I am uncertain whether we should fix it because it does
> > > mean a (very minor) change of behaviour. I tend to 'yes'.
> >
> > I have just committed a fix.
> >
> > Olli
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple performance improvement Re: m:n relations mapping...
Hello Andy,
I will have a look at it when I have time.
Please post messages like this to the OJB
users' or developers' list.
Thank you,
Olli
-Original Message-
From: Andy Malakov [mailto:[EMAIL PROTECTED]
Sent: Friday, October 31, 2003 9:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple performance improvement Re: m:n relations mapping...
Excellent.
Now how about going one step further and eliminating extra SELECT ? :-)))
We do not need to retrieve link table entries in case of new objects.
Class: org.apache.ojb.broker.core.PersistenceBrokerImpl:
Method: storeCollections(Object obj, Vector vecCds, boolean insert)
Line: 789
Now:
...
if (cds.isMtoNRelation())
{
currentMtoNKeys = getMtoNImplementor(cds, obj);
// delete unused m:n implementors
if (!insert)
{
deleteMtoNImplementor(cds, obj, (Collection)col, currentMtoNKeys);
}
}
Better:
...
if (cds.isMtoNRelation())
{
if (insert) {
currentMtoNKeys = java.util.Collections.EMPTY_LIST; // assume no
link table entries exist for new objects
} else {
currentMtoNKeys = getMtoNImplementor(cds, obj);
// delete unused m:n implementors
deleteMtoNImplementor (cds, obj, (Collection) col,
currentMtoNKeys);
}
}
I tested it with P6SPY - the above fix makes extra SELECTs disappear.
This two fixes make batch inserts of complex object work faster :-)
Thanks a lot for you product,
Andy
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 31, 2003 4:41 AM
Subject: RE: Simple performance improvement Re: m:n relations mapping...
> Hello,
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >
> > I am uncertain whether we should fix it because it does
> > mean a (very minor) change of behaviour. I tend to 'yes'.
>
> I have just committed a fix.
>
> Olli
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple performance improvement Re: m:n relations mapping...
Hello, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > I am uncertain whether we should fix it because it does > mean a (very minor) change of behaviour. I tend to 'yes'. I have just committed a fix. Olli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple performance improvement Re: m:n relations mapping...
Hello, > -Original Message- > From: Andy Malakov [mailto:[EMAIL PROTECTED] > Problem: Right after insert, PersistenceBrokerImpl calls > storeCollections () method that performs redundant DELETE FROM... > operation. The problem has been mentioned by myself in the developer list together wit a fix and a discussion whether to fix it. performance: surpress m:n collection deletion on insert > Solution: It should be possible to pass current operation > type update/insert to storeCollections () and avoid calling > deleteMtoNImplementor() in case of insert. This operation > type is always available in any caller method. > > P.S. Can somebody from OJB development confirm this message, please? done. I am uncertain whether we should fix it because it does mean a (very minor) change of behaviour. I tend to 'yes'. Olli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Simple performance improvement Re: m:n relations mapping...
Hello All, UseCase: PersistenceBroker stores NEW object that has non-decomposed m:n relationship field. Problem: Right after insert, PersistenceBrokerImpl calls storeCollections () method that performs redundant DELETE FROM... operation. Solution: It should be possible to pass current operation type update/insert to storeCollections () and avoid calling deleteMtoNImplementor() in case of insert. This operation type is always available in any caller method. P.S. Can somebody from OJB development confirm this message, please? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: m:n relations mapping...
There may be a better chance that somebody can help you if you post some snippets of the code you use to persist your objects. Gerhard "Hiu Yen Onn" <[EMAIL PROTECTED]> 16.10.2003 10:07 Bitte antworten an "OJB Users List" An: <[EMAIL PROTECTED]> Kopie: Thema: m:n relations mapping... how can i make a m:n mapping...? can u pls how??? i have been trying m:n decomposition method...but, the intermediary table is not persisted any data... actually, the data is persisted into the intermediary table, but then, it was deleted.. pls show the way to do it thanks... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
