[jboss-jira] [JBoss JIRA] Closed: (JBRULES-47) Named Facts

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.