[
http://jira.jboss.com/jira/browse/JBRULES-387?page=all ]
Edson Tirelli resolved JBRULES-387.
-----------------------------------
Fix Version/s: 3.0.4
Resolution: Done
Problem fixed and commited in revision #5823 (3.0.x branch):
=============
JBRULES-387:
* Fixing NOT and JOIN node problems on modify tuple
* Adding test case
$ svn commit
Sending drools-compiler/src/test/java/org/drools/Cheese.java
Sending
drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Adding
drools-compiler/src/test/resources/org/drools/integrationtests/test_LogicalAssertionWithExists.drl
Sending drools-core/src/main/java/org/drools/reteoo/JoinNode.java
Sending drools-core/src/main/java/org/drools/reteoo/NotNode.java
Sending drools-core/src/main/java/org/drools/reteoo/TerminalNode.java
Transmitting file data ......
Committed revision 5823.
==============
Fixed in trunk in revision #5824:
==============
$ svn commit
Sending drools-compiler/src/test/java/org/drools/Cheese.java
Sending
drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Adding
drools-compiler/src/test/resources/org/drools/integrationtests/test_LogicalAssertionWithExists.drl
Sending drools-core/src/main/java/org/drools/reteoo/JoinNode.java
Sending drools-core/src/main/java/org/drools/reteoo/TerminalNode.java
Transmitting file data ....
Committed revision 5824.
==============
Please, let me know if you find any other problem.
Also, please note that by definition, logical asserts in JBRules are equals() based, so if
one does not implement equals()/hashcode() methods in logically asserted classes, there is
a possibility that multiple objects will be asserted into memory for a single rule.
Edson
Using exists together with facts of the same type can break
auto-retraction of logically asserted objects
---------------------------------------------------------------------------------------------------------
Key: JBRULES-387
URL:
http://jira.jboss.com/jira/browse/JBRULES-387
Project: JBoss Rules
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Reteoo
Affects Versions: 3.0.3
Environment: Windows XP, java 1.5
Reporter: Geoffrey De Smet
Assigned To: Edson Tirelli
Fix For: 3.0.4
Attachments: JBRULES-387-testcase-trunk.patch, JBRULES-387.zip, screenshot-1.jpg
I assert 3 Lesson objects in my memory.
I got 1 rule, which creates logically asserted HardConstraint objects.
In some cases (not always), those logically asserted objects aren't retracted when
they should be, which leads to HardContaints just adding more and more. They aren't
logically retracted as they should be when:
- exists is combined with fact selections of the same class
- the modified object trigged the rule by the exists part, not by the the fact selection
part
I 'll attach a maven 2 configured proof of concept to repreduce it:
mvn install eclipse:eclipse idea:idea
Run net.sf.tabudrool.app.TabudroolApp
Click "Load unsolvedSchedule2.xml" (the second button on the left)
Notice the HardConstraint = 2 at the bottom
Click "Move lesson"
Move "[net.sf.tabudrool.domain.Lesson-1] 0: teacher0 + group0" to timeslot 1.
Notice that HardConstraint = 3 instead 1 at the bottom,
because - as you can see in the log - the previous HardConstraint objects didn't get
retracted.
Here's the drl:
rule teacherCanOnlyTeachOneGroupAtATime
when
$lesson : Lesson($id : id, $teacher : teacher, $timeslot : timeslot)
exists Lesson(id > $id, teacher == $teacher, timeslot == $timeslot)
then
System.out.println(" teacherCanOnlyTeachOneGroupAtATime: " + $lesson);
assertLogical(new HardConstraint(1));
end
Here's a log:
teacherCanOnlyTeachOneGroupAtATime: [net.sf.tabudrool.domain.Lesson-1] 0: teacher0 +
group0
teacherCanOnlyTeachOneGroupAtATime: [net.sf.tabudrool.domain.Lesson-0] 0: teacher0 +
group0
[ObjectAsserted: handle=[fid:9:9];
object=net.sf.tabudrool.domain.HardConstraint@1f42731]
[ObjectAsserted: handle=[fid:10:10];
object=net.sf.tabudrool.domain.HardConstraint@53abbb]
2006-08-03 19:24:35,796 [AWT-EventQueue-0] INFO
net.sf.tabudrool.swingui.WorkflowFrame$MoveAction.actionPerformed(WorkflowFrame.java:201)
Moving [[net.sf.tabudrool.domain.Lesson-1] 0: teacher0 + group0] to [1]
[ObjectModified: handle=[fid:7:11]; old_object=[net.sf.tabudrool.domain.Lesson-1] 1:
teacher0 + group0; new_object=[net.sf.tabudrool.domain.Lesson-1] 1: teacher0 + group0]
teacherCanOnlyTeachOneGroupAtATime: [net.sf.tabudrool.domain.Lesson-1] 1: teacher0 +
group0
[ObjectAsserted: handle=[fid:11:12];
object=net.sf.tabudrool.domain.HardConstraint@1c8b884]
As you can see: net.sf.tabudrool.domain.HardConstraint@1f42731 and
net.sf.tabudrool.domain.HardConstraint@53abbb weren't retracted (at least one should
be).
Earlier this week I posted a dud jira issue, as far as I can tell from discussing on irc
(with conan), this looks like a genuine issue...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira