[
https://issues.jboss.org/browse/JBRULES-3317?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3317:
-------------------------------------------
Annotations and stuff:
@PlanningVariable gets nullable : boolean
@PlanningVariable gets uninitializedSelectionFilter : SelectionFilter
Effects of having a nullable planning variable:
Local Search moves can put a planning variable back to null
Pretty straightforward, just add null to the planning value range
Construction heuristics (CH)
CH only fills in all vars, unless the uninitializedSelectorFilter filters them
out.
non-nullable var
uninitializedSelectorFilter defaults to var == null
nullable var
unintializedSelectoFilter defaults to nothing
everything is considered uninitialized
If CH choses to fill it in with null, that’s fine.
CH needs to make sure it fills in each vars no more than once
When to apply the uninitialized filter in CH?
Example: a solution will be "good enough" when only one of the two
trains reaches its destination. in this case, once I have one train reaching the
destination, I can safely assume the other to be Nullable.
By using no higher than cacheType STEP the filter will be called at every
step
Planner should support a null planning value
--------------------------------------------
Key: JBRULES-3317
URL:
https://issues.jboss.org/browse/JBRULES-3317
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Several users on the user mailing list have run into this, especially for task assignment
use cases.
Example use case:
@PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee
There are so many Tasks, that's better to not assign some Tasks for now.
Current workaround:
Make a Employee representing NONE,
which is the only Employee instance that returns true on employee.isNone()
and the score rules are written to deal with that.
Technical difficulty to fix:
The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to
be "uninitialized".
Partial uninitialized solution detection is fundamental for repeated planning (including
real-time planning),
because the construction heuristics need to detect which parts of the solution to
intialize, but not everything because that takes too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira