1) Usually non hard coded constraint suffice. For example, instead of having a constraint that says:
- "when Ann is working on Friday, penalize"
there is:
- A DayOfWeekDislike data class with an Employee and a DayOfWeek.
** The input data has an instance that with employee Ann and dayOfWeek Friday.
- There is a constraints that says: "when there is a DayOfWeekDislike and there is a ShiftAssignment of that employee to such a DayOfWeek, penalize"
This approach suffices in most of the use cases to avoid dynamic constraints. Notice that you can add/remove DayOfWeekDislike data in real-time with Solver.addProblemFactChange()
.
2) Next, @ConstraintConfiguration
can use @ConstraintWeight
to disable/enable constraints in real time with Solver.addProblemFactChange()
. Set a constraint weight to a zero score to disable it.
3) If both 1) and 2) fail, you really need dynamic constraints. I haven't seen any use case that needs to go this far yet, but we could support it. If you do need this approach, what's your use case?