Re: [rules-users] Drools Planner: what if possible values of a PlanningVariable are dependent of another one?

On 08-05-14 14:38, dBijkoo wrote: No Phase caching moves is definitely NOT the way to go :) Phase caching means it caches as moves at the beginning of the solver phase. So as some variables change value in steps, the possible move set doesn't. I believe this approach will hit the wall when you try to add a move that changes the 2 variables of an entity in a single move. Side note: To do this, you can configure a <cartesianProductMoveSelector> of 2 <changeMoveSelector> for which the second has an <entitySelector> that mimics the first one's. IIRC, the course timetabling example has such a config example. What will happen is that it will select a variable for the period from the range of the Observation's old block and meanwhile also change the block. There's a number of features this approach won't allow you to do (and I might not recall all of them). Because I want to solve this problem, without limiting so many features, I want to solve it differently in the future. +1 yes, definitely :) I understand the need for this problem, and why the current recommended solution is suboptimal (to large search space). Feel free to make a jira for the problem (not your proposed solution). My time is too limited to review code zips (unless it's a reproducer for an accepted bug). Anyway, what is the recommended solution? Not sure. A) Either just allow all combinations, that will work. B) Or try @Entity class Observation { @Variable block; } @Entity class Block { @Variable("periodRange) period; @VariableProvider("periodRange") getPeriodRange(); } Not sure if this matches for your case - multiple Observations might share the same Block for a different period... This is allowed - (it's called ValueRange from planning entity) and more deeply supported (although it does have a few limits too). C) Or try class BlockPeriod { Block; Period; } @Entity class Observation { @Variable BlockPeriod; } Hmm. I like alternative C!