[rules-dev] Bugs/Problems with 3.1.0M1

[Mark Proctor]

Sorry thats the stateful working memory interface, StatefulSession - 
just incase my opening paragraph confuses anyone.
Mark Proctor wrote:
> Q1) Stateless is just that, stateless, you pass it the facts, it 
> executes and is done. If you need continuous access to the 
> WorkingMemory use the StatefulWorkingMemory interface, which actually 
> extends the WorkingMemory interface. Can you show me a use case where 
> you neeed access to the WorkingMemory from a StatelessSession, where 
> you shouldn't be using a StatefulSession to begin with.
>
> Q2) Synchronized working memory is no longer needed, and to be honest 
> wasn't very good, as the WorkingMemory itself is now thread safe - 
> except the Iterators, but we'll eventually add thread safe adaptors 
> for them. Thats why its 4.0, instead of 3.1, signifying a break in 
> API. the changes really aren't that big and we don't want to create a 
> confusing and heavy api due to legacy support.
>
> Q3.1 Shadow facts are needed if you want to work with POJOs and the 
> modify command, you should only disable them (i.e. use final) if you 
> know the object is immutable, if a class is final we can't extend it 
> with code generation and thus can't generate shadow facts for it, even 
> if we wanted to. The reason for this is we need to know the previous 
> value, prior to the modification. We are working on a way in which 
> shadow facts aren't needed, this involves not allowing "modify" 
> outside of the consequence and within the consequence we actually 
> retract the fact before any modifications and assert it after the 
> modifications are finished.
>
> Q3.2 isShadowEnabled is for internal purposes only at the moment, thus 
> no setter. Once we have the code finish to allow optional shadow facts 
> we will expose some api for configuring this.
>
> There is a lot of R&D going on and this a difficult field - it often 
> takes many attempts to get stuff right which results in a lot of 
> refactoring - but we do work on code simplication, just look at the 
> drools-compiler dialect API compared to how it is in 3.0 (where it was 
> called semantic), a huge change and massive simplifications as we move 
> towards pluggeable dialects.
>
> Decision Tables in Excel are limited, although very business friendly, 
> to get any real power and flexability we need to be looking to 
> integrated this into Eclipse - due to limited resources, not sure if 
> that will get done any time soon - patch welcome :)
>
>
> Arjun Dhar wrote:
>> Hi,
>>  firstly, I compiled my code from 3.0 to 3.1 had issues, then from 
>> 3.1 to 4, I cant access my working memory from my rule base and in 4 
>> you've also got rid of Synchronized working memory.
>>
>> Questions :
>> ===========
>>
>> Related to shift from 3.1 to 4
>> -------------------------------
>> Q1. Once I create a 'StatelessSession'; how do I extract the 
>> Workingmemory? There is no acessor. My code was written for 
>> 'SynchronizedWorkingMemory' so means double trouble if there is no 
>> backward compatibility.
>> Q2. Couldn't you guys have deprecated stuff instead of just wiping it 
>> off? Is there a reason for such a change as to restrict access to 
>> WorkingMemory or SynchronizedWorkingmemory to those who would have 
>> got comfortable using it directly? :o)
>>
>> Related to shift from 3.0 to 3.1
>> ---------------------------------
>> 3. When I built my code on 3.1M1 the first thing I got was a 
>> NullPointerException, I debugged the code and found due to additon of 
>> ShadowFacts, if the class definition is NOT FINAL, it dynamically 
>> creates a Shadow object. Refer: 
>> org.drools.semantics.java.builder.ColumnBinder.java (1st Method) 
>> {Sweet!} ...BUT:
>>
>>    Q3.1. Whats a Shadow got to do with a Class being final????????? 
>> (If 4 wasnt released I'd say keep it that way, atleast I could 
>> disable shadow facts as a work around)
>>    Q3.2. To use Shadow or not comes from 
>> "org.drools.spi.ObjectType.isShadowEnabled()"; there is no Setter for 
>> this. So apart from making a class 'final'  or defining a custom 
>> 'FactTemplate' one does not have any option.    Q3.3. When I looked 
>> at 4 code, this code has disappeared (or probably got refactored 
>> somewher I couldnt find it)
>> Final Question: Whats the deal guys? :o) Its hard enough looking at 
>> the code of one version, but when I see drastic code change it makes 
>> one wonder if at this rate changes, it's hard :o) Hope you understand.
>>
>> Please let me know the answer to my questions!
>> Recommendation: I see a lot of acceptance on Decision Tables compared 
>> to DSL. Once the code settles will give you guys some recommendations 
>> + code there, but in the mean time please provide feature support to 
>> decsion tables as well as you do for DRL, in future. If one can 
>> manage decision tables well, I see a lot of power in getting people 
>> to accept rule engines compare to other approaches.
>>
>> Thanks!
>>
>> _______________________________________________
>> 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
>