[rules-dev] Bugs/Problems with 3.1.0M1

[Mark Proctor]

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
>
>