[rules-dev] Shadow Facts

[Mark Proctor]

After a long walk and thinking about shadow facts I think the only way 
forward is to remove modify(....) from drl consequences. Modify will 
exist external via the WorkingMemory interface, but shadow facts must be 
turned on for that class for it to work.

To allow a series of setters for a single propagation to be done in a 
drl we must move to one of the following the following syntaxes:
person(name = mark, age = 31)
person.setValues(name = mark, age = 31)
person.(name = mark, age = 31)

Or some variation of the above, we will then use regular expression on 
known declarations to turn  person(name = mark, age = 31) into :
retract( person, MODIFY ); person.setName( mark ); person.setAge( 31 ); 
assert( person, MODIFY );
The MODIFYis a keyword to indicate that the propagation is a MODIFICATION

PropertChangeListeners shouldn't have an issue as we can dictate that 
they also do a retract and assert, before and after the setting of the 
value. Hmm if you are in a consequence and modify a field on a 
propertychangelistener fact, you'll need to detect whether the regexp or 
the fact handles the retract + assert.

I still have plans to "weave" facts to allow them to seamlessly handle 
modifies, I had a mock up implementation for this (uncommitted) and lost 
it when I sent my laptop back to dell, forget to back it up :( Still 
shouldn't take long to remake that.


Mark Proctor wrote:
> I think it will be hard. My preference is to change the drl to do a 
> retract+assert on a modify, that way we don't need shadow facts - as 
> long as they keep the modifies strictly inside the drl - which I think 
> is fair.
>
> Mark
> Edson Tirelli wrote:
>>
>>   Mark,
>>
>>   I can tell you for sure that the overhead is not linear. It is 
>> worst then that.
>>   For that user asserting up to 1million facts, as the rules have 
>> just a few partial matches, the overhead makes the performance be 
>> worst than 3.0.x branch.
>>
>>   One question and one comment:
>>
>> Comment: I still don't like the design of current proxy. As you 
>> remember, we do lazy proxy, but equals/hashcode methods had to be 
>> overriden to avoid strange behavior and they now call proxy methods 
>> to get the values to compare. It means, even being lazy, once 
>> anything in the engine call hashcode/equals methods, it will load all 
>> attributes into the proxy. It basically removes any benefit of being 
>> lazy.
>>
>> Question: how easy do you think we can do binding/constraint 
>> analyzis, in order to: 1) automatically disable shadow facts for 
>> facts that do not change bound/constrained attributes and 2) maybe 
>> limit the proxy caching to only those methods?
>>
>>    Just brainstorming here...
>>
>>   []s
>>   Edson
>>
>> Mark Proctor 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
>>> 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
>