Bug 1197784

Summary: Optaplanner sometimes ignores different scoreDefinitionType and runs anyway.
Product: [Retired] JBoss BRMS Platform 6 Reporter: jvahala
Component: OptaPlannerAssignee: Geoffrey De Smet <gdesmet>
Status: CLOSED EOL QA Contact: Lukáš Petrovický <lpetrovi>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 6.1.0CC: kverlaen, lpetrovi
Target Milestone: DR1   
Target Release: 6.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 19:05:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description jvahala 2015-03-02 15:38:49 UTC
Description of problem:
I've observed that some phases in planner runs well despite of wrongly set scoreDefinitionType in configuration. For instnace construction heuristics creates TSP problem from OptaplannerExamples although there is different score option in configuration than SimpleLong, which is used by TSP.    


Expected results: I would expect some exeption explaining that there are different score types. Or If planner is so clever it is able to determine score type from domain itsel, it would be good if there was no option in config such as "scoreDefinitionType". 

But some phases (for example BRANCH_AND_BOUND) can't deal with this wrong config option anyway, which is be expected. But if it is expected here, it should be expected everywhere.

Comment 2 Geoffrey De Smet 2015-03-19 13:45:43 UTC
Interesting case. BruteForce doesn't need the ScoreDefinition, so it's the Solution<FooScore> and ScoreCalculator<FooScore>'s score type that is used (and they must match). Nevertheless, this should fail fast of course, so I am fixing it.

Note: If a Drools score calculator is used, the wrong scoreDefinition does fail fast due to clashing with the score holder in the DRL.

Comment 4 Geoffrey De Smet 2015-03-19 14:06:58 UTC
Not backported to 6.2.x because blocker tag is missing (and I don't think it's needed)

Comment 5 jvahala 2015-08-06 07:47:46 UTC
Verified. (as we discussed earlier that fixing this consistency breaks backward compatibility)