[ https://issues.apache.org/jira/browse/OFBIZ-11040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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<GenericValue> 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<GenericValue> 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} > <eca entity="GoodIndentification" operation="create-store-remove" > event="return"> > <action service="indexProduct" mode="sync"/> > </eca> > {code} > And > {code:java} > delegator.removeByAnd('GoodIdentification', [productId: 'WG-1111']) > {code} > The service indexProduct wasn't call for the productId WG-1111 > 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)