Bug 1197784 - Optaplanner sometimes ignores different scoreDefinitionType and runs anyway.
Summary: Optaplanner sometimes ignores different scoreDefinitionType and runs anyway.
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: OptaPlanner
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: DR1
: 6.2.0
Assignee: Geoffrey De Smet
QA Contact: Lukáš Petrovický
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-02 15:38 UTC by jvahala
Modified: 2020-03-27 19:05 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:05:20 UTC
Type: Bug


Attachments (Terms of Use)

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)


Note You need to log in before you can comment on or make changes to this bug.