How to filter ProblemFactCollectionProperty in entity range provider?

[holger brandl]

Hi,

we have the following model:

@PlanningSolution

public class ProductionSchedule {

    @ProblemFactCollectionProperty
    @ValueRangeProvider(id = "toolRange")
    private List<Tool> tools;

...

}

@PlanningEntity

class Task(val type: String){

    @PlanningVariable(
        valueRangeProviderRefs = ["toolRange"]
    )
    var tool: Tool? = null

...

}

How can we filter the collection when creating the computing for a `type`-dependent task? We know that we could have the range provider in the entity class, but there we do not have a reference to the `tools` collection.

We also know that this could be modelled as constraint, but since there are cases where only 1 tool is in the range we would love to make the model more efficient.

Kind regards,

Holger

[Lukáš Petrovický]

Holger,

On Tue, Jan 18, 2022 at 2:13 PM holger brandl <holger...@gmail.com> wrote:

We also know that this could be modelled as constraint, but since there are cases where only 1 tool is in the range we would love to make the model more efficient.

As far as I know, planning entities can reference the planning solution in their constructors. (The solution cloner should be able to handle that.) Therefore, if you bring in the solution through the entity constructor, you get access to all its fields. 

--

Lukáš Petrovický

He/Him/His

Principal Software Engineer, Business Automation

lukas.pe...@redhat.com    IM: triceo/lpetrovi

My work week is Monday to Thursday.

[holger brandl]

Thanks Lukáš,

Sorry for the corrupted grammar, I hit "send" too early.  The correct question was: How can we filter the fact collection `toolRange` for a `type`-dependent task? 

Your suggestion would indeed solve our use-case. Do you by chance have a pointer to an example? Maybe there is a special syntax/convention when adding the solution as a constructor argument?

Best,

Holger

[Lukáš Petrovický]

On Tue, Jan 18, 2022 at 2:23 PM holger brandl <holger...@gmail.com> wrote:

Your suggestion would indeed solve our use-case. Do you by chance have a pointer to an example? Maybe there is a special syntax/convention when adding the solution as a constructor argument?

I am not sure what you mean by "example". What you are looking for is a way of having problem facts inside planning entities. At one point somewhere in your code, you will have to put them there. :-)

There are options how you could do that:

- When constructing the entity instance, pass the solution to the constructor of the entity.

- If the solution gets created after the entities, set the solution to the entity via a setter.

- If the entire thing is being loaded from the database, you may perhaps denormalize your schema and have the individual tasks directly joined to the applicable tool types.

I'm sure that list is by no means exhaustive. Pick an option that works best for your use case.

 

[Lukáš Petrovický]

On Tue, Jan 18, 2022 at 3:07 PM Lukáš Petrovický <lpet...@redhat.com> wrote:

- If the entire thing is being loaded from the database, you may perhaps denormalize your schema and have the individual tasks directly joined to the applicable tool types.

My apologies for the use of the word "denormalize" - I got ahead of myself. :-) What I mean is that you may need to create a new table with a product of tasks and applicable tool types. No need to bring denormalization into it.

 

[holger brandl]

Thanks a lot. I'll try the setter approach. 

Best

Holger