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
: 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
, 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
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
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
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
