[rules-dev] Drools.Frustration

[Mark Proctor]

  On 12/08/2010 02:37, Alex Besogonov wrote:
> Good $time_of_day!
>
> I'm a Drools newbie trying to use it in production. So I want to share
> some of my frustration and some of my solutions to this frustration :)
>
> First, let's start with insertLogical - it's useless. It can easily
> mislead user into thinking that changed objects are retracted. Of
> course, other users bumped into it before me:
> http://drools-java-rules-engine.46999.n3.nabble.com/insertLogical-and-modifyRetract-td57727.html
> , but the proposed resolution is ugly.
If you are using Drools 5.0 or 5.1 you no longer need modifyRetract and 
modifyInsert, they were hacks due to the use of shadow facts in Drools 
4.0, which no longer exist.

Also please stick to interfaces and methods provided in drools-api.

Likewise the other issue from that posting is fixed and no longer an 
issue if you use 5.1. https://jira.jboss.org/browse/JBRULES-1804

Don't forget to implement equals and hashcode for logicaly inserted 
facts, as the TMS depends on those to work.
> So I wrote a wrapper around the 'insertLogical' function which
> introduces the notion of 'fact key', so only one fact with the given
> key can exist in the working memory at a time. To borrow the example
> in the referenced mail thread:
> ============
> rule "fact = 1"
>     when
>         $f : UserFact(fact1 == 1);
>     then
>           insertLogical(new CreatedFact($f.getFact2()));
> end
> ============
> Becomes:
> ============
> global ConsequenceHelper ch; # Code of the ConsequenceHelper is attached
>
> rule "fact = 1" language "mvel"
>     when
>         $f : UserFact(fact1 == 1);
>     then
>           ch.insertGuarded(drools, new CreatedFact($f.getFact2()),
> {$f.getFact2()}); # Here {$f.getFact2()} is the CreatedFact's key.
> end
> ============
> So if this rule fires again, the stale object will be retracted and
> the newly created object will be asserted. It would be nice to see
> something like this integrated into the Drools core...
>
As mentioned above, already fixed in 5.1 :)
> Next, I'd like to say something about Drools LHS language. Well, it's
> VERY confusing. I spent two hours debugging internals of MVEL to
> understand why this doesn't work:
> ============
> rule "Double Shift OT"
>         dialect "mvel" agenda-group "OT Calculation"
> when
>         $at : AcctTransaction()
>         exists(AcctTransaction(this!=$at, acct.plannedEndTimestamp
> coincides[2h] $at.plannedStartTimestamp))
> then
> ...
> end
> ============
> Turns out, I can't use these nice Drools Fusion predicates to for deep
> properties. It would be nice, if it was at least mentioned somewhere
> in the documentation. No workaround for this one, I had to write
> global helper functions.
That should work, have you tried 5.1? If it doesn't please open a JIRA 
and we'll attemt to fix it.

We are currently simplifying our backend for LHS which will remove the 
confusion of whether it's drools or mvel doing the evaluation. Which 
should simplify things.
>
> And the final problem (so far). Drools has this nice 'from' feature
> which allows to use objects not in the working memory. However, it's
> not possible to do this:
> ============
> rule "Blah"
> when
>     $l : Long() from new Long(42L)
> then
> ...
> end
> ============
> I had to write a helper function which just returns its parameter to
> work around this one.
For now you can do this:
Long() from return( new Long(42) )

It's a parser limitation, we are trying to improve it.
>
> And the final note - DRL is too cut&pasty. There's no _good_ way to
> reuse predicates used in the LHS (there's rule inheritance, but it's
> not always applicable) and actions in the RHS.
Always open to suggestions. Better still, get involved and help us 
improve things :)

Mark
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20100812/70b4e5c0/attachment-0001.html