Re: [droolers] Trying to get a clue.

[Dave Bryson]

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