Done in trunk at r1524704
Jacques
Jacques Le Roux wrote:
Hi Paul,
Yes that should be the way indeed. We should do it before creating R13
Jacques
From: Paul Foxworthy p...@cohsoft.com.au
Hi Adrian and Jacques,
If doCacheClear will have no effect, I suggest deprecating the method
Hi Paul,
Yes that should be the way indeed. We should do it before creating R13
Jacques
From: Paul Foxworthy p...@cohsoft.com.au
Hi Adrian and Jacques,
If doCacheClear will have no effect, I suggest deprecating the method
signature with the doCacheClear. It can call another overloaded
Hi Adrian and Jacques,
If doCacheClear will have no effect, I suggest deprecating the method
signature with the doCacheClear. It can call another overloaded variant
without that parameter. All calls in trunk should be changed to the second.
We can leave the deprecated version for backwards
Adrian,
In javadoc of numbers of methods of Delegator.java you added this sentence
- *boolean that specifies whether to clear related cache entries
- *for this primaryKey to be created
+ *boolean that specifies whether or not to automatically clear
We could change the code to always clear the cache, but leave the method
signature the same and mention in the JavaDocs that the doCacheClear
parameter will be ignored.
-Adrian
On 5/11/2013 12:54 PM, Jacques Le Roux wrote:
Adrian,
In javadoc of numbers of methods of Delegator.java you added
(sorry for previous message; seems my email client did me a joke)
Then I would also add a warning in log.
But I'm not quite sure all this would be enough.
It'd be better to refactor it, to remove any possible confusions. Fortunately
those methods seems to not be much used OOTB.
Of course
Jacques Le Roux wrote:
(sorry for previous message; seems my email client did me a joke)
Then I would also add a warning in log.
But I'm not quite sure all this would be enough.
It'd be better to refactor it, to remove any possible confusions. Fortunately
those methods seems to not be
