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
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
