I'm assigning rooms to lessons in my schedule generator. My current model looks like this:
@PlanningEntity
class Lesson {
...
@PlanningVariable(allowsUnassigned = true)
Room room;
Set<String> requiredRoomAttributes;
...
}
class Room {
Set<String> attributes;
}
However, I need to change it so that each lesson can have an arbitrary (but fixed) number of rooms. (In the user interface the user can specify that a lesson needs three rooms with three different set of required attributes.)
(A @PlanningListVariable
does not seem suitable here since each room can be assigned to multiple lessons as long as the lessons don't collide in time.)
A natural way to model this would be something like:
@PlanningEntity
class Lesson {
...
Set<RoomAssignment> roomAssignments;
...
}
class RoomAssignment {
...
Room room; // null until room has been assigned
Set<String> requiredRoomAttributes;
...
}
class Room {
Set<String> attributes;
}
I'm puzzled though because I'm not sure where to put the @PlanningVariable
annotation. I assume it must be on the entity, but it's only the room
(not the requiredRoomAttributes
that is the actual variable).
This leads me to believe that this is a better modelling:
@PlanningEntity
class Lesson {
...
@PlanningVariable
List<Room> rooms;
// The i:th set represents the requirements for the i:th room
List<Set<String>> requiredAttributes;
...
}
class Room {
Set<String> attributes;
}
Question 1: Is this the recommended way to model this problem, or is there a better way?
Question 2: Is there any chance any built in move selector could be used to update individual elements in List<Room> rooms
, or should I go ahead and write custom move selectors?
Question 3: Correct me if I'm wrong, but I feel like Timefold internally probably could handle an arbitrary (but fixed) list of independent variables. Has this ever been considered? For example something like:
@PlanningEntity
class Lesson {
@PlanningVariableArray
Room[] rooms = new Room[10];
}
Question 1: Since "each lesson can have an arbitrary (but fixed) number of rooms", I would model it like this
class Lesson {
Set<RoomAssignment> roomAssignments;
}
@PlanningEntity
class RoomAssignment {
...
@PlanningVariable
Room room; // null until room has been assigned
Set<String> requiredRoomAttributes;
...
}
class Room {
Set<String> attributes;
}
so the planning entity is now room assignment instead of the lesson.
Question 2: With the model I used in my answer to Question 1, all built-in move selectors will work.
Question 3: Generally speaking, arbitrary (but fixed) variables are handled with the "element is entity" strategy that is used in my answer to Question 1. This strategy has the additional benefit of making it easier to write incremental constraints (since you don't need to iterate a collection or array to check the planning value of an entity).