On 08-05-14 10:08, dBijkoo wrote: In OptaPlanner's architecture current philosophy, this is not legal: a value range should be stable for each variable (of each entity) during solving. This not guaranteed to work (and it is guaranteed not to work if you do phase caching of moves: it will invalidly exclude part of the search space). If it does work for you, I am interested to know more about this - so I can consider to make this approach legal.

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!

ignore post above misread your statement about option B Option B will not work if a block contains multiple observations as you stated, which is the case in my problem. -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Drools-Planner-what-if-poss... Sent from the Drools: User forum mailing list archive at Nabble.com.