sigh... these are getting more numerous :(
This is a question for the user mailing list, you want to know how to
"use" drools, you are not asking on how to develope drools itself.
Please read this thoroughly:
I am looking for some lightweight solution of fact sets separation
withing single working memory. ... I am possibly messing up with
terminology therefore please let me present an example.
I have set of facts
"Set 1" contains:
- Fact ( name==A, property==1)
- Fact ( name==B, property==2)
"Set 2" contains:
- Fact ( name==A, property==1)
- Fact ( name==C, property==2)
- I would like to execute my dedicated package of rules for
instance of "Set 1" within single working memory.
- When "Set 1" is inserted ( instantiated ) twice or more into the
working memory I would like to separate the scope of rules to
this particular instance
- I would like to insert "Set 2" at the same time multiple times
and execute separate set of rules dedicated for "Set 2" separately
on each of inserted instance of "Set 2"
- In some cases I would like to have access to facts from other
instances of different sets within same working memory. eg.:
- rule associated to "Set 1" checks all the occurrences of
Fact( name == A ) - means it could read state of Fact
from other instances of "Set 1" and "Set 2"
- rule associated to "Set 1" checks state of fact associated
to Fact ( name == A ) from "Set 2"
I could do it currently by
- adding extra fact indicating instance to working memory
- adding property to my Fact indicating origin ( instance in this case )
- altering each rule.
Example: reaching facts in particular instance
...
when:
Instance ( instanceId: id, name == "Set 1")
Fact ( ... , origin == instanceId )
...
then
( ... )
Example: reaching fact in multiple instances
...
when:
Fact (...)
...
then
Idea behind is very prosaic. Majority of the rules are written
in my case with single instance context in mind. Only sometimes
there is a need to look out of the "hedge".
So my example requires more typing and better specification
for *modeler* ( name of the role in my org - means person who
writes the rules ) who is using simpler single *model*
( set of rules + set of facts ).
I am trying to implement this using multiple, chained working
memories but maintenance of graph of working memories does
not look very practical for longer term and its not working
perfectly.
How could it be implemented - high level of course
Or better ... How I would like to use it :)
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
ruleBase.addPackage ( "Set1" , MyPackageForSet1 );
// 1st argument is context name, 2nd compiled rule package
WorkingMemory wm = ruleBase.newStatefulSession();
wm.insertInContext ( "Set1", new Fact (A,1) ) // this could be also
solved by implementing interface on the fact
// inserting instance and context pointer after fact creation
// and then inserting it to wm regular way.
than if there would be a need to reach fact from other
contexts I would specify it using something-like-this syntax
...
when
Fact ( ... ) // facts within same context and instance
*.Fact ( ... ) // facts from all facts sets (contexts)
<ContextName>.Fact ( ... ) // facts from all
// instances of specific context.
<ContextName>(*).Fact ( ...) // same as above
<ContextName>(1).Fact ( ...) // facts from specific
// instance of specific context.
Ok. What I am looking here.
- is something like this possible now out of the box and
I skipped this nice chapter in documentation?
- does it make sense from your point of view to implement this
kind of functionality. In my case it has lets say business
justification and will allow to implement really complex solutions in
nice way.
- Does this problem have some buzzwordish/scientifically blessed
name so I can express it better next time or maybe find something
interesting in mailing list archive.
(Changing subject to something more sufficient is more the welcomed )
- is it at all possible ;)
- what I am missing in this problem description?
And big thanks for reading it till the end.
tk.
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev