-
Feature Request
-
Resolution: Done
-
Major
-
3.0-rc2
-
None
If two objects A and B are asserted, where A != B, but A.eqals(B) is true, then drools adds both of them to working memory, creating two fact handles. Behaviour is based on using org.drools.util.IdentityMap as identityMap in Reteoo workingMemoryImpl
My request is to add another behaviour and customizable which to use.
Drools should assert an object B, if there is not already an object A in working memory where A.equals(B) is true. (Basically this behaviour is achieved by using HashMap instead of IdentityMap)
Customization should be possible via setting properties on workingMemory creation. In JSR94 it would be a property for createRuleSession:
HashMap properties = new HashMap();
properties.put("org.drools.objectequality", "equals");
//properties.put("org.drools.objectequality", "identity"); //default value
StatefulRuleSession session = (StatefulRuleSession)ruleRuntime.createRuleSession(executionSetName, properties, RuleRuntime.STATEFUL_SESSION_TYPE);
- Currently, properties are used to set global variables. So "org.drools.objectequality" would yield unknown global error.
[JBRULES-266] Customize how drools checks if an object is already asserted in its working memory
John Doe (Inactive)
added a comment - Problem with WM_BEHAVIOR_EQUALS and modifying initially unequal objects becoming equal. See comment + attached files: test_ModifyToEquality.drl + modifyToEquality.clp
John Doe (Inactive)
added a comment - Problem with WM_BEHAVIOR_EQUALS and modifying initially unequal objects becoming equal. See comment + attached files: test_ModifyToEquality.drl + modifyToEquality.clp John Doe (Inactive)
added a comment - If assertion behaviour is WM_BEHAVIOR_EQUALS (either for normal or logically asserted facts) there are potential problems in the case that a modify of a fact happens, that makes it equal to some other fact. Do they "merge" into one fact or continue to exists equal but separate? Currently I believe they continue to exist as equals, but that yields problems, as some checks I assume can't distinguish between the two facts or they appear as one.
Testcase test_ModifyToEquality.drl attached. I had to modify org.drools.Cheese to CheeseEqual and implement hashCode() and equals(). Classfile can be found at:
http://jira.jboss.com/jira/browse/JBRULES-233
This is in general an interesting problem and more a matter of definition of behaviour of modify I guess. If modify is interpreted as rectract+assert then the facts should be merged. But that would yield problems as e.g. the 2 fact-handles pointing to 2 separate objects would then either point to the same or one fact-handle would become invalid.
In case of merging and logically assertion: Justifications would have to be updated, for the 2 merging objects + objects logically depending on these two.
JESS 7.0b7 does also have problems with that. Attached modifyToEquality.clp, yields errors for cases described.
John Doe (Inactive)
added a comment - If assertion behaviour is WM_BEHAVIOR_EQUALS (either for normal or logically asserted facts) there are potential problems in the case that a modify of a fact happens, that makes it equal to some other fact. Do they "merge" into one fact or continue to exists equal but separate? Currently I believe they continue to exist as equals, but that yields problems, as some checks I assume can't distinguish between the two facts or they appear as one.
Testcase test_ModifyToEquality.drl attached. I had to modify org.drools.Cheese to CheeseEqual and implement hashCode() and equals(). Classfile can be found at:
http://jira.jboss.com/jira/browse/JBRULES-233
This is in general an interesting problem and more a matter of definition of behaviour of modify I guess. If modify is interpreted as rectract+assert then the facts should be merged. But that would yield problems as e.g. the 2 fact-handles pointing to 2 separate objects would then either point to the same or one fact-handle would become invalid.
In case of merging and logically assertion: Justifications would have to be updated, for the 2 merging objects + objects logically depending on these two.
JESS 7.0b7 does also have problems with that. Attached modifyToEquality.clp, yields errors for cases described. Feature added in revision 4333.
Now, a RuleBaseConfiguration object exists and it may be used to create rule bases with configurable behavior, such as:
- Assert behavior: either identity or equals based
- Logical assert behavior: either identity or equals based. Although, if identity is chosen, regular assert behavior will also be set to identity.
- Beta left memory indexing: on / off
- Beta right memory indexing: on / off
- Alpha hashing inside ObjectTypeNodes: on/off
- Alpha hashing inside AlphaNodes: on/off
There is a limitation though. To keep rulebase consistency, once a rule base is created, behavior can not be changed anymore and the associated configuration object is made immutable.
Let me know if any problem is detected.
Edson
Mark Proctor
added a comment - This shouldn't be too hard to do. So we only ever allow one equals instance of a class - this is probalby just a slightly reording of logic in working memory assert. If you can provide a patch and comprehensive unit test for this weekend, and its obvious the code is stable I'll commit this for 3.0. Which we will hopefully final for next week.
We already have PackageBuilderConfiguration - which takes its defaults from system properties - we can have a RuleBaseConfiguration. Infact I thought we already had this to turn on/off indexing - but it looks like it wasn't done. Look at PackageBuilder and PackageBuliderConfiguration, and copy that approach for RuleBase. Liaise with Edson Tirelli to update this RuleBaseConfiguration to handle index configuration for org.drools.rete.beta classes.
It's important that we abstract System properties away from main code, via these Configuration objects - which have hard coded defaults that can be overriden by either a system property or a programmatic setter.
Mark Proctor
added a comment - This shouldn't be too hard to do. So we only ever allow one equals instance of a class - this is probalby just a slightly reording of logic in working memory assert. If you can provide a patch and comprehensive unit test for this weekend, and its obvious the code is stable I'll commit this for 3.0. Which we will hopefully final for next week.
We already have PackageBuilderConfiguration - which takes its defaults from system properties - we can have a RuleBaseConfiguration. Infact I thought we already had this to turn on/off indexing - but it looks like it wasn't done. Look at PackageBuilder and PackageBuliderConfiguration, and copy that approach for RuleBase. Liaise with Edson Tirelli to update this RuleBaseConfiguration to handle index configuration for org.drools.rete.beta classes.
It's important that we abstract System properties away from main code, via these Configuration objects - which have hard coded defaults that can be overriden by either a system property or a programmatic setter. 
logical assertions are always equality based. Stated facts can now use identity and equality - using your configuration settings. I have added another configuration setting to dictate how logical over-ride works. Does it discard the original fact, or turn it into two stated fact handles.