[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-4956:
--------------------------------------
Description:
Having a constraint like
{code:java}
Person($customer == name)
{code}
is not really the same thing as
{code:java}
Person(name == $customer)
{code}
In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
was:
Having a constraint like
{code:java}
Person( name == "Toshiya" )
{code}
is not really the same thing as
{code:java}
Person( "Toshiya" == name )
{code}
In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
> Normarize rule constraints for property reactivity and indexing
> ---------------------------------------------------------------
>
> Key: DROOLS-4956
> URL: https://issues.redhat.com/browse/DROOLS-4956
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.31.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Having a constraint like
> {code:java}
> Person($customer == name)
> {code}
> is not really the same thing as
> {code:java}
> Person(name == $customer)
> {code}
> In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 5:01 AM:
--------------------------------------------------------------------
Note:
{code:java}
Person( "Toshiya" == name )
{code}
works for property reactivity thanks to
MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case).
was (Author: tkobayashi):
Note:
{code:java}
Person( "Toshiya" == name )
{code}
works for property reactivity thanks to
MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case).
{code:java}
Person($customer == name)
{code}
This can cause a property reactivity issue.
> Normarize rule constraints for property reactivity and indexing
> ---------------------------------------------------------------
>
> Key: DROOLS-4956
> URL: https://issues.redhat.com/browse/DROOLS-4956
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.31.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Having a constraint like
> {code:java}
> Person($customer == name)
> {code}
> is not really the same thing as
> {code:java}
> Person(name == $customer)
> {code}
> In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-4956:
--------------------------------------
Description:
Having a constraint like
{code:java}
Person(name == $customer)
{code}
is not really the same thing as
{code:java}
Person($customer == name)
{code}
In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
was:
Having a constraint like
{code:java}
Person($customer == name)
{code}
is not really the same thing as
{code:java}
Person(name == $customer)
{code}
In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
> Normarize rule constraints for property reactivity and indexing
> ---------------------------------------------------------------
>
> Key: DROOLS-4956
> URL: https://issues.redhat.com/browse/DROOLS-4956
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.31.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Having a constraint like
> {code:java}
> Person(name == $customer)
> {code}
> is not really the same thing as
> {code:java}
> Person($customer == name)
> {code}
> In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 4:59 AM:
--------------------------------------------------------------------
Note:
{code:java}
Person( "Toshiya" == name )
{code:java}
works for property reactivity thanks to
MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case).
{code:java}
Person($customer == name)
{code:java}
This can cause a property reactivity issue.
was (Author: tkobayashi):
Note: Person( "Toshiya" == name ) works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case).
> Normarize rule constraints for property reactivity and indexing
> ---------------------------------------------------------------
>
> Key: DROOLS-4956
> URL: https://issues.redhat.com/browse/DROOLS-4956
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.31.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Having a constraint like
> {code:java}
> Person( name == "Toshiya" )
> {code}
> is not really the same thing as
> {code:java}
> Person( "Toshiya" == name )
> {code}
> In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 5:00 AM:
--------------------------------------------------------------------
Note:
{code:java}
Person( "Toshiya" == name )
{code}
works for property reactivity thanks to
MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case).
{code:java}
Person($customer == name)
{code}
This can cause a property reactivity issue.
was (Author: tkobayashi):
Note:
{code:java}
Person( "Toshiya" == name )
{code:java}
works for property reactivity thanks to
MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case).
{code:java}
Person($customer == name)
{code:java}
This can cause a property reactivity issue.
> Normarize rule constraints for property reactivity and indexing
> ---------------------------------------------------------------
>
> Key: DROOLS-4956
> URL: https://issues.redhat.com/browse/DROOLS-4956
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.31.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Having a constraint like
> {code:java}
> Person( name == "Toshiya" )
> {code}
> is not really the same thing as
> {code:java}
> Person( "Toshiya" == name )
> {code}
> In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-4956:
-------------------------------------------
Note: Person( "Toshiya" == name ) works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case).
> Normarize rule constraints for property reactivity and indexing
> ---------------------------------------------------------------
>
> Key: DROOLS-4956
> URL: https://issues.redhat.com/browse/DROOLS-4956
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.31.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Having a constraint like
> {code:java}
> Person( name == "Toshiya" )
> {code}
> is not really the same thing as
> {code:java}
> Person( "Toshiya" == name )
> {code}
> In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4973) Defined collection unary checks do not pass
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4973:
-----------------------------------
Summary: Defined collection unary checks do not pass
Key: DROOLS-4973
URL: https://issues.redhat.com/browse/DROOLS-4973
Project: Drools
Issue Type: Bug
Components: Scenario Simulation and Testing
Affects Versions: 7.32.0.Final
Reporter: Jozef Marko
Assignee: Daniele Zonca
Attachments: MySpace_eshop.zip
Import the attached project and click Build, then Test.
The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months