]
Mark Proctor closed JBRULES-47.
-------------------------------
Resolution: Out of Date
redundant now that we have bound inserts, via Commands.
Named Facts
-----------
Key: JBRULES-47
URL:
https://jira.jboss.org/jira/browse/JBRULES-47
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-core (expert)
Reporter: Mark Proctor
Assignee: Mark Proctor
There are times when you want to match facts by name, rather than by type+constraints. If
we define a fact in an external process as
Cheese stilton = new Cheese();
stilton.setType("stilton");
workingMemory.assertObject(stilton);
The correct way to match this is object type match + field constraints:
stilton:Cheese(type == "stilton")
However there may be cases where you want to know that the bound variable stilton is
bound to the same instance that the stilton variable references in the external
application. This can be achieved via wrappers, similar to how primitive wrappers work:
Cheese stilton = new Cheese();
stilton.setType("stilton");
NamedFact stiltonNamedFact = new NamedFact("stilton", stilton);
drools.assertObject(stiltonNamedFact);
We can then have rules that do
NamedFact( type=="org.cheesery.Cheese", type == "stilton",
stilton:value )
This first constraints the rule to the correct NamedFact and then binds the wrapped value
to the stilton declaration. This can be further improved with syntactic sure to automate
the boxing and unboxing of the fact
drools.assertNamedObject("stilton", stilton);
And in the rule we do
rule "buy cheese"
var stilton;
when
.....
then
end
or maybe vars could be defined in a parameter fashion
rule "buy cheese"(stilton)
when
.....
then
end
Caveat:
This is generally a really bad idea and abused by people who still don't get the rule
engine paradigm of pattern matching - and would use this though out their rule design. If
you tie the matching process to named variables, extensively throughout, the engine
becomes "hamstrung" and cannot optimise, turning Drools into nothing more than a
BSF like scripting framework - its like buying a Ferrari to go to the local shops and
back. It's also a "code smell" in that it breaks the declarative rule logic
encapsulation paradigm in that the filtering/matching is tied to an external procoss -
coupling the processes together.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: