You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Mathieu Lirzin (JIRA)" <ji...@apache.org> on 2019/05/18 16:00:00 UTC
[jira] [Comment Edited] (OFBIZ-11040) Manage EECAs on
delegator.removeBy
[ 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)