-
Bug
-
Resolution: Done
-
Blocker
-
None
-
None
Currently the order is arbitrary.
For example:
genuine varA has a shadow varB
genuine varA has a shadow varC
shadow varB has a shadow varD
shadow varC also has a shadow varD
The order should be: varA, varB, varC, varD.
The order should not be: varA, varB, varD, varC, varD again. That's wasteful.
- causes
-
PLANNER-393 Broken TransportTimeToHubUpdatingVariableListener in Coach shuttle gathering
- Resolved
-
PLANNER-471 VariableListenerSupport.beforeVariableChanged() is severly slower (from CR1 to CR2) due to SortedMap usage
- Resolved
-
PLANNER-472 VariableListenerSupport.beforeVariableChanged() is severly slower (from CR1 to CR2) due to HashSet.add() usage
- Resolved
-
PLANNER-318 AnchorShadowVariable responsible for NullPointerException creating a ScoreDirector
- Resolved
-
PLANNER-482 NonUniqueNotificationVariableListener to forgo unique notification requirement in favor of performance gain
- Resolved
- is blocked by
-
PLANNER-400 Detect cyclic shadow variables and fail fast
- Resolved
- is duplicated by
-
PLANNER-388 way to specify order of CustomShadowVariable
- Resolved
- is incorporated by
-
PLANNER-299 Vehicle Routing
- Resolved
- relates to
-
PLANNER-315 2 shadow vars updated by the same variable listener should not require 2 variable listener instances
- Resolved