[rules-dev] Shadow Facts

[Mark Proctor]

I guess its more to do with the drl.

We currently have:
count.setValue(.....);
modify( count );

now I can do a regexp that changes
count.setValue(....); to
retract( count ); count.setValue(...); assert( account );

But then what happens if the user used modify. One of the advantages of 
using modify(....) is you control when the progation occurs, ideal if 
you are updating lots of values on the same object. And ofcourse i have 
the backward compatability issue.

Mark
Peter Lin wrote:
>
> you could go with the option of having a parameter for the assert.
>
> if the user knows they absolutely don't want shadow and plan to assert 
> 1million facts, they can assert without shadow. otherwise they can 
> call the default assert.
>
> jamocha's assert has 4 parameters
> assertObject(Object data, String template, boolean statc, boolean shadow)
>
> of course if someone uses JSR94, they won't be able to do anything 
> beyond the stupid API
>
> peter
>
> On 2/10/07, *Mark Proctor* <mproctor at codehaus.org 
> <mailto:mproctor at codehaus.org>> wrote:
>
>     I'm finding that in manners shadow facts add on average about 10% or
>     under to execution times.
>
>     test by changing:
>     count.setValue(  count.getValue() + 1 );
>     modify( count );
>
>     To (with shadow facts turned off)
>     retract( count );
>     count.setValue(  count.getValue() + 1 );
>     assert( count );
>
>     The problem I'm having is finding a generic and clean way to make
>     shadow
>     facts configurable and have the .drl adapt appropriately, without the
>     user having to manually do retract and asserts, instead of a modify.
>
>     Having had feedback from users that are asserting a huge number of
>     facts
>     (approx 1mill) into the working memory, having the ability to not
>     deal
>     with shadowfacts will improve performance and memory, more so than in
>     the case of manners. I'd be interested ot know if the 10% or less rule
>     is still true with those large numbers, and also the size in memory.
>
>     Mark
>
>     _______________________________________________
>     rules-dev mailing list
>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20070211/0363d362/attachment.html