Where to put "@PlanningEntityCollectionProperty" when "@ValueRangeProvider" is in "@PlanningEntity"?

[luckebar]

I am trying to filter the available employees for each Shift (PlanningEntity) because there are many cases (vacation, illness, forced rest) for which an employee can never be assigned to a shift. To do this, as per the documentation , I put the list of in the shift (entity) to ensure that only the employees who are available for a given shift are returned. I do not want to accept solutions that use an unavailable employee. I can not understand where to make the ConstraintProvider take the list through the ProblemFactCollectionProperty annotation, in my opinion it should take it from the shift and not from the solution but the documentation says that it can only be inserted in the PlanningSolution.

[TomCools]

See the Timeslots in our Conference Scheduling example:
https://github.com/TimefoldAI/timefold-quickstarts/blob/stable/java/conference-scheduling/src/main/java/org/acme/conferencescheduling/domain/ConferenceSchedule.java

Planning Solution contains only the @ProblemFactCollectionProperty
@ProblemFactCollectionProperty private Set<Timeslot> timeslots;

The PlanningEntity contains the value range provider:
@ValueRangeProvider public Set<Timeslot> getTimeslotRange() { return talkType.getCompatibleTimeslots(); }

Do take a second to read about the negative effects of placing the ValueRangeProvider annotation in the entity in case you haven't. https://docs.timefold.ai/timefold-solver/latest/using-timefold-solver/modeling-planning-problems#valueRangeProviderOnPlanningEntity.

What you describe (availability) can also be handled using constraints, see our quickstart.

[luckebar]

Thanks, I will look at the example you indicated.
I have already read the possible negative effects but in some cases it could happen, in my case, that half of the employees are not available for half of the period to be optimized and another half is available for the remaining part.
We work a lot with temporary contracts.
In this case I could really significantly reduce the number of possible solutions.
I wanted to at least do a test to compare this with a hard constraint.
I also thought about using one or the other real-time solution depending on the case.

[luckebar]

In the example, I understand that I still need to pass the full list of my ProblemFacts to the Solution as well as making sure that each Entity has its own filtered list, right?

[triceo]

Correct. Whatever you don't provide as problem facts or planning entities, it will not be available in Constraint Streams.

But you can use the planning solution in the constructor of your planning entity - and that way, you can filter the data directly from the solution, as opposed to somehow assigning them to the entity in your dataset.

[luckebar]

Thanks a lot.