[
https://issues.apache.org/jira/browse/OFBIZ-11040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843191#comment-16843191
]
Mathieu Lirzin edited comment on OFBIZ-11040 at 5/18/19 3:59 PM:
-
Hello at a first look, The {{ecaCache}} local variable seems not used anywhere
and the initialization of {{hasEntityEcaRules}} to {{false}} is useless.
In the following line what the expected behavior of the cache for entity
without EECA. does it have a binding to a {{null}} or empty collection, or does
it just have no binding?
{code:java}
hasEntityEcaRules = UtilValidate.isNotEmpty(
EntityEcaUtil.getEntityEcaCache(entityEcaReaderName).get(entityName));
{code}
I am sure there is a good reason, but I don't understand why we are checking
for removed entities only in test mode and when EECA are found. Maybe an inline
comment in code would help.
Additionally I would recommend avoiding variable re-assignment and {{null}}
usage when possible like that:
{code:java}
List removedEntities = (testMode || hasEntityEcaRules)
? findList(entityName, condition, null, null, null, false)
: Collections.emptyList();
int rowsAffected= 0;
if (!removedEntities.isEmpty()) {
...
}
{code}
Thanks.
was (Author: mthl):
Hello at a first look, The {{ecaCache}} local variable seems not used anywhere
and the initialization of {{hasEntityEcaRules}} to {{false}} is useless.
In the following line what the expected behavior of the cache for entity
without EECA. does it have a binding to a {{null}} or empty collection, or does
it just have no binding?
{code:java}
hasEntityEcaRules = UtilValidate.isNotEmpty(
EntityEcaUtil.getEntityEcaCache(entityEcaReaderName).get(entityName));
{code}
I am sure there is a good reason, but I don't understand why we are checking
for removed entities only in test mode and when EECA are found. Maybe an inline
comment in code would help.
Additionally I would recommend avoiding variable re-assignment and {{null}}
usage when possible like that:
{code:java}
List removedEntities = (testMode || hasEntityEcaRules)
? findList(entityName, condition, null, null, null, false)
: Collections.emptyList();
int rowsAffected= 0;
if (removedEntities.isEmpty()) {
...
}
{code}
Thanks.
> Manage EECAs on delegator.removeBy
> --
>
> Key: OFBIZ-11040
> URL: https://issues.apache.org/jira/browse/OFBIZ-11040
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Minor
> Attachments: OFBIZ-11040.patch
>
>
> Currently, when you delete some entities through removeByAnd or
> removeByCondition, eeca aren't enable and the remove is quite as regard
> implemented rules.
> With
> {code:java}
> event="return">
>
>
> {code}
> And
> {code:java}
> delegator.removeByAnd('GoodIdentification', [productId: 'WG-'])
> {code}
> The service indexProduct wasn't call for the productId WG-
> To solve this situation, the idea would be delegator.removeValue for each
> element to delete when an eeca is present otherwise call the standard
> helper.removeByCondition.
> This patch [^OFBIZ-11040.patch] provided by [~mleila]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
