[rules-dev] Justifying favorite colors

Mark Proctor mproctor at codehaus.org
Sun Jan 13 15:11:27 EST 2008


Geoffrey De Smet wrote:
> Conan and I had a discussion whether the current behavior of drools 
> has a bug or a feature. What do you think?
>
> Let's say I have a Person STATED fact:
>  - Person: name=John, favoriteColor=RED
>  - Person: name=Elvis, favoriteColor=GREEN
>  - Person: name=Tom, favoriteColor=GREEN
> Person has an equals/hashcode based on the name only.
>
> I also have a logically asserted ExistingFavoriteColor
> which just takes a color and has a equals/hashcode based on the color.
>
> So now we have a rule which logically asserts all existing favorite 
> colors:
>
> rule "favoriteColor"
>   when
>     Person($color : favoriteColor)
>   then
>     insertLogical(new ExistingFavoriteColor($color));
> end
>
> So if we fire all rules the first time, there will be 2 existing 
> favorite colors: RED and GREEN.
>
> Next, John changes his mind, and has a new favoriteColor YELLOW.
> When all rules are fired, what exisiting favorite colors would you 
> expect?
>
> a) YELLOW and GREEN because no one likes RED anymore
> b) RED, YELLOW and GREEN because John used to like RED
>
The relationship of ExistingFavouriteColor is based on the truth of the 
rule+data that executed it. By changing the color you have not broken 
the truth of the rule, therefor it cannot know to retract the logically 
asserted object.  The engine currently has no understanding of the 
relationship of a bound field, that is not constraint, to a logically 
asserted object.

If sounds like what you are asking is this:
If a logical asserted object holds a reference to a bound field and that 
field impcts the hashcode/equality of the logically asserted fact. Then 
while the rule continues  to be true if that bound filed changes it 
should no longer be justified and thus it should be removed.





More information about the rules-dev mailing list