On Mon, 28 Jan 2002, bob mcwhirter wrote:
> Would it be possible (maybe inconvenient) to break these into multiple
> rules, one for each portion of the condition?
>
> ie;
>
> rule-1:
> name = 1
This is what I ended up doing:
I create an object the encapsulates the result
set from the DB and assert it into working memory (following the shopping
cart experiment). I then start with a rule that loops over the iterator
and asserts each model bean into the engine, then apply the other rules.
Then key point for me was to encapsulate this information into a container
like object to pass to the rule engine.
>
> > Also, each rule may have more than one name/value pair.
> > And if the number of name/value pairs > 1 then AND them together
> >
> > Example:
> >
> > nameX=1 OR 2 OR 3
> > AND
> > nameY= A OR B OR etc...
>
> I guess this may result in combinatorial explosion, no, using the
> method I just prescribed above...
> rule-1a:
>
> nameX = 1
> nameY = A
>
> rule-1b:
>
> nameX = 1
> nameY = B
>
Yes it does. The rules apply to a single model ( model being
a bean that represents a row in the database ).
So I can have a rule that looks like this.
<rule-1>
<cond>
model.getA() = X || model.getA() = Y
</cond>
<cond>
model.getB().equals("hello") || model.getB().equals("yes");
</cond>
etc...
> Are you doing it against all things in the database, effectively being
> a query? Are you doing a SELECT * first, creating objects, and then
> intending to pass them through drools?
Yes. I intended at first to modify the query BEFORE executing it.
This would seem to be more efficient, however this approach limits
flexibilty because I don't always know what the query may be asking for.
Essentially, I'm implemeting record and column level security. Rules
also apply to writes/deletes.
> Thus far, I haven't allowed OR expressions in the rules-file syntax,
> due to analysis complexities. Some OR expressions should/will be
> allowed, but only those that result in the same 'active' objects,
> regardless of which portion of the OR expression matched.
>
> ie, this would be BAD.
>
> if name="bob" OR age=28
>
> This should be okay:
>
> name="bob" OR name="billy"
>
> Using the SPI, though, you are not limited to what I've allowed with
> the rules-file analysis. You can do anything you want, including
> a Condition that does OR type expressions internally.
I think eventually I'll need to implement a little domain specific
language to make it somewhat easier for administrators to setup/test/and modify
rules. Hopefully with a little language I can help prevent the analysis
complexities you mention above. For example, In my case, the asserted
models are beans so I could use a UI to load and introspect them
to help users build the proper constraints ( e.g. model.getA(), etc... )
I'll also need to implement a pluggable loader for the RulesLoader to
be able to read rules from a DB etc... I'd be happy to contibute it back if
there's any need.
Thanks for the help.
Dave
--
Dave Bryson
[EMAIL PROTECTED]
_______________________________________________
drools-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/drools-interest
