[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