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)