-
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
-