[rules-users] new to Drools: modeling issues

[Gabor Szokoli]

Hi again,

thanks again!

2010/12/6 Swindells, Thomas <TSwindells at nds.com>:
> In my experience no-loop is pretty much worthless as it only prevents the
> most trivial type of loops (a rule reactivating itself).  It provides no
> help for the most common type of loop where multiple rules modify the same
> object and reactivate each other.

That's why I'm trying to establish the idiom of testing for the
opposite of the "modify" action result.
As long as the modify action is idempotent, I should be OK.

I'm secretly hoping I'll be able to automate this in the DSL later on,
albeit the lack of reflection in "modify" is troubling.
(making the attributes public is always an option, just not nice.)

> From: rules-users-bounces at lists.jboss.org
> [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Michael Anstis

> Glad you're reading the documents - you'd be surprised how many people
> asking questions do not!

Well, I have not finished them all either :-)

> You can put off DSL until you're happy your rules are working, off course -
> in fact, IMO, it's easier to "debug" rules without the additional
> abstraction.
>
> You're first rule looks better - although I'd still be inclined to look at
> no-loop rather than the check yourself (what if you need the new value to be
> dynamic; i.e. not just statically "value"? Your rules would become
> cumbersome).

I'd extract it to be the last term of the condition, and muse under my
beard how the rule engine should allow me to use the same syntax in
"modify", and do the check automatically:

modifyAttribute($object.attribute) { ... }

I understand this can't work for people doing procedural stuff, side
effects, non-trivial setters, etc, but I sure would love it, and they
can just not use it :-)

> The second rule does not associate StringHolder to any particular Child
> instance (although easily added); so you'd get the cross-product of
> StringHolders and Child facts; not I suspect what you'd want.

Ahh, the dog ate my equals sign:
<<<
 $attribute : StringHolder(get()!="value")
 $child: Child(parent==$parent ... attribute==$attribute)
>>>

But the real question here is how I can make Drools treat my
attributes as the atomic unit of "fact" instead of objects?
Will I be able to cover up this added level of indirection with a DSL?


Gabor Szokoli