Adding to your analysis: when looking at the "Building ConstraintOccurrence summary" for the presumed working memory we can see what is wrong (the cause includes the collection of matching ShiftAssignment to IntervalRequirement). Also keep in mind that there is only one instance of a ShiftAssignment (starting at 100 and going from 1 to 4 in duration), versus 4 instances of IntervalRequirement (interval # from 100 to 103):
2011-12-05 22:21:49,678 [main] TRACE Adding ConstraintOccurrence (intervalRequirementCovered/NEGATIVE_HARD:[IntervalRequirement: interval: 101, position id: 1, staffingRequired: 2, [ShiftAssignment: emp. id: 10 [st: 100, dur: 1]]]=1) Here it matched wrongly the ShiftAssignment. Nothink should have been matched since the ShiftAssignment covers only interval 100. Weight should have been 2 instead of 1. 2011-12-05 22:21:49,678 [main] TRACE Adding ConstraintOccurrence (intervalRequirementCovered/NEGATIVE_HARD:[IntervalRequirement: interval: 100, position id: 1, staffingRequired: 2, [ShiftAssignment: emp. id: 10 [st: 100, dur: 1], ShiftAssignment: emp. id: 10 [st: 100, dur: 1]]]=0) Here that's the oddest. The ShiftAssignment should be matched, however the cause shows that it matched *twice* the same and only one ShiftAdjustment. Weight should have been 1 instead of 0. Maybe this odd behavior would ring some bells? -- View this message in context: http://drools.46999.n3.nabble.com/Planner-5-3-Final-presumedScore-is-corrupted-when-using-update-on-the-rules-working-memory-tp3546932p3567517.html Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
