Changes in RC-2 syntax
Locked
Changes in RC-2 syntax
 
|
The following used to work in previous versions (though I'm not sure which),
rule "All Application Traffic by Org Unit Template Selection Logic" when qo : QueryObject(selectApplication == true) qo : QueryObject(selectUser == true) qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) then qo.setTemplate("AppUserByOU.ftl"); end But when I upgraded to RC-2 in order to get it to fire I needed to change it to this, rule "All Application Traffic by Org Unit Template Selection Logic" when qo : QueryObject(selectApplication == true, selectUser == true, orgNetObjectType == ObjectType.pmi_net_user, reportType == Constants.REPORT_TYPE_WINDOW) then qo.setTemplate("AppUserByOU.ftl"); end Which is fine, I understand that the latter is completely resolved within the alpha/pattern network, but what impact will it have on my ability to define DSL? It seems the former would lend itself to a more straightforward DSL implementation. Also, it seems that the former should still be valid, though less efficient. -Mitch |
Re: Changes in RC-2 syntax
|
Thats a reallly really really bad rule - unless I misunderstand what you
are doing. you are creating a cross product of 16 with that, although we now remove instance equals cross product. So that means you would have to assert 4 QueryObjects for this to work. If it was working before thats because the rule was firing repeatedly for the same object and doing the same set, so you weren't noticing. To understand what I mean try this in RC1 and RC2 in the audit view and you will understand the difference. Mitch Christensen wrote: > The following used to work in previous versions (though I'm not sure which), > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true) > > qo : QueryObject(selectUser == true) > > qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) > > qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > But when I upgraded to RC-2 in order to get it to fire I needed to change it > to this, > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true, > > selectUser == true, > > orgNetObjectType == > ObjectType.pmi_net_user, > > reportType == > Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > Which is fine, I understand that the latter is completely resolved within > the alpha/pattern network, but what impact will it have on my ability to > define DSL? It seems the former would lend itself to a more straightforward > DSL implementation. > > > > Also, it seems that the former should still be valid, though less efficient. > > > > -Mitch > > > > > |
RE: Changes in RC-2 syntax
|
|
Wow, that wasn't my understanding at all.
Going from my (admittedly vague) recollection from Jess, referencing the same fact-binding variable ('qo' in my case) across conditions means that the same fact instance must be used across all conditions. In other words the value of 'qo' must be equal across the rule. I agree that without fact-binding a cross product would result, but I thought that the fact/pattern binding eliminated this. -Mitch -----Original Message----- From: Mark Proctor [mailto:[hidden email]] Sent: Wednesday, April 19, 2006 10:43 AM To: [hidden email] Subject: Re: [drools-user] Changes in RC-2 syntax Thats a reallly really really bad rule - unless I misunderstand what you are doing. you are creating a cross product of 16 with that, although we now remove instance equals cross product. So that means you would have to assert 4 QueryObjects for this to work. If it was working before thats because the rule was firing repeatedly for the same object and doing the same set, so you weren't noticing. To understand what I mean try this in RC1 and RC2 in the audit view and you will understand the difference. Mitch Christensen wrote: > The following used to work in previous versions (though I'm not sure which), > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true) > > qo : QueryObject(selectUser == true) > > qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) > > qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > But when I upgraded to RC-2 in order to get it to fire I needed to change > to this, > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true, > > selectUser == true, > > orgNetObjectType == > ObjectType.pmi_net_user, > > reportType == > Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > Which is fine, I understand that the latter is completely resolved within > the alpha/pattern network, but what impact will it have on my ability to > define DSL? It seems the former would lend itself to a more > DSL implementation. > > > > Also, it seems that the former should still be valid, though less efficient. > > > > -Mitch > > > > > |
Re: Changes in RC-2 syntax
|
|
In Drools 3.0 that is true of bound field variables, which is the same
in jess. I haven't done it on Columns. If this is the case in Jess I'll look to add support for it in 3.1 - but I don't see why someone would want to write a rule like that. Mark Mitch Christensen wrote: > Wow, that wasn't my understanding at all. > > Going from my (admittedly vague) recollection from Jess, referencing the > same fact-binding variable ('qo' in my case) across conditions means that > the same fact instance must be used across all conditions. > > In other words the value of 'qo' must be equal across the rule. > > I agree that without fact-binding a cross product would result, but I > thought that the fact/pattern binding eliminated this. > > -Mitch > > -----Original Message----- > From: Mark Proctor [mailto:[hidden email]] > Sent: Wednesday, April 19, 2006 10:43 AM > To: [hidden email] > Subject: Re: [drools-user] Changes in RC-2 syntax > > Thats a reallly really really bad rule - unless I misunderstand what you > are doing. you are creating a cross product of 16 with that, although we > now remove instance equals cross product. So that means you would have > to assert 4 QueryObjects for this to work. If it was working before > thats because the rule was firing repeatedly for the same object and > doing the same set, so you weren't noticing. > > To understand what I mean try this in RC1 and RC2 in the audit view and > you will understand the difference. > > > Mitch Christensen wrote: > >> The following used to work in previous versions (though I'm not sure >> > which), > >> >> >> rule "All Application Traffic by Org Unit Template Selection Logic" >> >> when >> >> qo : QueryObject(selectApplication == true) >> >> qo : QueryObject(selectUser == true) >> >> qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) >> >> qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) >> >> then >> >> qo.setTemplate("AppUserByOU.ftl"); >> >> end >> >> >> >> But when I upgraded to RC-2 in order to get it to fire I needed to change >> > it > >> to this, >> >> >> >> rule "All Application Traffic by Org Unit Template Selection Logic" >> >> when >> >> qo : QueryObject(selectApplication == true, >> >> selectUser == true, >> >> orgNetObjectType == >> ObjectType.pmi_net_user, >> >> reportType == >> Constants.REPORT_TYPE_WINDOW) >> >> then >> >> qo.setTemplate("AppUserByOU.ftl"); >> >> end >> >> >> >> Which is fine, I understand that the latter is completely resolved within >> the alpha/pattern network, but what impact will it have on my ability to >> define DSL? It seems the former would lend itself to a more >> > straightforward > >> DSL implementation. >> >> >> >> Also, it seems that the former should still be valid, though less >> > efficient. > >> >> >> -Mitch >> >> >> >> >> >> > > > > |
Re: Changes in RC-2 syntax
|
I think a good reason for being able to have multiple conditions on separate lines is that it is easier to define a DSL.
Mark Proctor <[hidden email]> wrote: In Drools 3.0 that is true of bound field variables, which is the same in jess. I haven't done it on Columns. If this is the case in Jess I'll look to add support for it in 3.1 - but I don't see why someone would want to write a rule like that. Mark Mitch Christensen wrote: > Wow, that wasn't my understanding at all. > > Going from my (admittedly vague) recollection from Jess, referencing the > same fact-binding variable ('qo' in my case) across conditions means that > the same fact instance must be used across all conditions. > > In other words the value of 'qo' must be equal across the rule. > > I agree that without fact-binding a cross product would result, but I > thought that the fact/pattern binding eliminated this. > > -Mitch > > -----Original Message----- > From: Mark Proctor [mailto:[hidden email]] > Sent: Wednesday, April 19, 2006 10:43 AM > To: [hidden email] > Subject: Re: [drools-user] Changes in RC-2 syntax > > Thats a reallly really really bad rule - unless I misunderstand what you > are doing. you are creating a cross product of 16 with that, although we > now remove instance equals cross product. So that means you would have > to assert 4 QueryObjects for this to work. If it was working before > thats because the rule was firing repeatedly for the same object and > doing the same set, so you weren't noticing. > > To understand what I mean try this in RC1 and RC2 in the audit view and > you will understand the difference. > > > Mitch Christensen wrote: > >> The following used to work in previous versions (though I'm not sure >> > which), > >> >> >> rule "All Application Traffic by Org Unit Template Selection Logic" >> >> when >> >> qo : QueryObject(selectApplication == true) >> >> qo : QueryObject(selectUser == true) >> >> qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) >> >> qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) >> >> then >> >> qo.setTemplate("AppUserByOU.ftl"); >> >> end >> >> >> >> But when I upgraded to RC-2 in order to get it to fire I needed to change >> > it > >> to this, >> >> >> >> rule "All Application Traffic by Org Unit Template Selection Logic" >> >> when >> >> qo : QueryObject(selectApplication == true, >> >> selectUser == true, >> >> orgNetObjectType == >> ObjectType.pmi_net_user, >> >> reportType == >> Constants.REPORT_TYPE_WINDOW) >> >> then >> >> qo.setTemplate("AppUserByOU.ftl"); >> >> end >> >> >> >> Which is fine, I understand that the latter is completely resolved within >> the alpha/pattern network, but what impact will it have on my ability to >> define DSL? It seems the former would lend itself to a more >> > straightforward > >> DSL implementation. >> >> >> >> Also, it seems that the former should still be valid, though less >> > efficient. > >> >> >> -Mitch >> >> >> >> >> >> > > > > --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. |
|
In reply to this post by Mark Proctor
let me see if I understand the problem correctly. if I were to translate
this to JESS clips (defrule "All Application Traffic by Org Unit Template Selection Logic" ?qo <- (QueryObject (selectApplication true) (orgNetObjectType true) (reportType "pmi_net_user") (reportType "REPORT_TYPE_WINDOW") ) => (set ?go template "AppUserByOU.ftl") ) Is that close to what you're thinking of in JESS? or were you thinking of something different? peter On 4/19/06, Mark Proctor <[hidden email]> wrote: > > In Drools 3.0 that is true of bound field variables, which is the same in > jess. I haven't done it on Columns. If this is the case in Jess I'll look to > add support for it in 3.1 - but I don't see why someone would want to > write a rule like that. > > Mark > Mitch Christensen wrote: > > Wow, that wasn't my understanding at all. > > Going from my (admittedly vague) recollection from Jess, referencing the > same fact-binding variable ('qo' in my case) across conditions means that > the same fact instance must be used across all conditions. > > In other words the value of 'qo' must be equal across the rule. > > I agree that without fact-binding a cross product would result, but I > thought that the fact/pattern binding eliminated this. > > -Mitch > > -----Original Message----- > From: Mark Proctor [mailto:[hidden email] <[hidden email]>] > Sent: Wednesday, April 19, 2006 10:43 AM > To: [hidden email] > Subject: Re: [drools-user] Changes in RC-2 syntax > > Thats a reallly really really bad rule - unless I misunderstand what you > are doing. you are creating a cross product of 16 with that, although we > now remove instance equals cross product. So that means you would have > to assert 4 QueryObjects for this to work. If it was working before > thats because the rule was firing repeatedly for the same object and > doing the same set, so you weren't noticing. > > To understand what I mean try this in RC1 and RC2 in the audit view and > you will understand the difference. > > > Mitch Christensen wrote: > > The following used to work in previous versions (though I'm not sure > > which), > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true) > > qo : QueryObject(selectUser == true) > > qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) > > qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > But when I upgraded to RC-2 in order to get it to fire I needed to change > > it > > to this, > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true, > > selectUser == true, > > orgNetObjectType == > ObjectType.pmi_net_user, > > reportType == > Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > Which is fine, I understand that the latter is completely resolved within > the alpha/pattern network, but what impact will it have on my ability to > define DSL? It seems the former would lend itself to a more > > straightforward > > DSL implementation. > > > > Also, it seems that the former should still be valid, though less > > efficient. > > > > -Mitch > > > > > > > > |
Re: Changes in RC-2 syntax
|
|
That is what he was hoping to do, but he thought this was equivalent
?qo <- (QueryObject (selectApplication true) ) ?qo <- (QueryObject (orgNetObjectType true) ) ?qo <- (QueryObject (reportType "pmi_net_user") ) ?qo <- (QueryObject (reportType "REPORT_TYPE_WINDOW") ) So he was hoping taht binding each Fact to the same variable would mean that it always pointed to the same instance. Now I know this is true for field bindings, once you bind it first, no idea if this is true for Fact bindings - seems kinda crazy. Mark Peter Lin wrote: > let me see if I understand the problem correctly. if I were to translate > this to JESS clips > > (defrule "All Application Traffic by Org Unit Template Selection Logic" > ?qo <- (QueryObject > (selectApplication true) > (orgNetObjectType true) > (reportType "pmi_net_user") > (reportType "REPORT_TYPE_WINDOW") > ) > => > (set ?go template "AppUserByOU.ftl") > ) > > Is that close to what you're thinking of in JESS? or were you thinking of > something different? > > peter > > > > On 4/19/06, Mark Proctor <[hidden email]> wrote: > >> In Drools 3.0 that is true of bound field variables, which is the same in >> jess. I haven't done it on Columns. If this is the case in Jess I'll look to >> add support for it in 3.1 - but I don't see why someone would want to >> write a rule like that. >> >> Mark >> Mitch Christensen wrote: >> >> Wow, that wasn't my understanding at all. >> >> Going from my (admittedly vague) recollection from Jess, referencing the >> same fact-binding variable ('qo' in my case) across conditions means that >> the same fact instance must be used across all conditions. >> >> In other words the value of 'qo' must be equal across the rule. >> >> I agree that without fact-binding a cross product would result, but I >> thought that the fact/pattern binding eliminated this. >> >> -Mitch >> >> -----Original Message----- >> From: Mark Proctor [mailto:[hidden email] <[hidden email]>] >> Sent: Wednesday, April 19, 2006 10:43 AM >> To: [hidden email] >> Subject: Re: [drools-user] Changes in RC-2 syntax >> >> Thats a reallly really really bad rule - unless I misunderstand what you >> are doing. you are creating a cross product of 16 with that, although we >> now remove instance equals cross product. So that means you would have >> to assert 4 QueryObjects for this to work. If it was working before >> thats because the rule was firing repeatedly for the same object and >> doing the same set, so you weren't noticing. >> >> To understand what I mean try this in RC1 and RC2 in the audit view and >> you will understand the difference. >> >> >> Mitch Christensen wrote: >> >> The following used to work in previous versions (though I'm not sure >> >> which), >> >> >> >> rule "All Application Traffic by Org Unit Template Selection Logic" >> >> when >> >> qo : QueryObject(selectApplication == true) >> >> qo : QueryObject(selectUser == true) >> >> qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) >> >> qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) >> >> then >> >> qo.setTemplate("AppUserByOU.ftl"); >> >> end >> >> >> >> But when I upgraded to RC-2 in order to get it to fire I needed to change >> >> it >> >> to this, >> >> >> >> rule "All Application Traffic by Org Unit Template Selection Logic" >> >> when >> >> qo : QueryObject(selectApplication == true, >> >> selectUser == true, >> >> orgNetObjectType == >> ObjectType.pmi_net_user, >> >> reportType == >> Constants.REPORT_TYPE_WINDOW) >> >> then >> >> qo.setTemplate("AppUserByOU.ftl"); >> >> end >> >> >> >> Which is fine, I understand that the latter is completely resolved within >> the alpha/pattern network, but what impact will it have on my ability to >> define DSL? It seems the former would lend itself to a more >> >> straightforward >> >> DSL implementation. >> >> >> >> Also, it seems that the former should still be valid, though less >> >> efficient. >> >> >> >> -Mitch >> >> >> >> >> >> >> >> >> > > |
RE: Changes in RC-2 syntax
|
|
In reply to this post by Peter Lin
I just checked Jess and it appears that facts bound across conditions
eliminate a cross product. The following Jess script and associated output demonstrates. -Mitch (deftemplate person (slot firstName) (slot lastName) (slot age)) (printout t "--No cross product" crlf) (defrule find-steve-30 ?person <- (person (firstName ?name)) ?person <- (person (age ?age&:(= ?age 30))) => (printout t "Found a guy named " ?name " who is " ?age crlf)) (assert (person (firstName steve)(age 22))) (assert (person (firstName steve)(age 30))) (assert (person (firstName bob)(age 30))) (run) (printout t "--With cross product" crlf) (defrule find-anyone-30 ?person <- (person (firstName ?name)) (person (age ?age&:(= ?age 30))) => (printout t "Found a guy named " ?name " who is " ?age crlf)) (run) --No cross product Found a guy named bob who is 30 Found a guy named steve who is 30 --With cross product Found a guy named bob who is 30 Found a guy named steve who is 30 Found a guy named bob who is 30 Found a guy named steve who is 30 Found a guy named steve who is 30 Found a guy named steve who is 30 6 -----Original Message----- From: Peter Lin [mailto:[hidden email]] Sent: Wednesday, April 19, 2006 11:15 AM To: Mark Proctor Cc: [hidden email] Subject: Re: [drools-user] Changes in RC-2 syntax let me see if I understand the problem correctly. if I were to translate this to JESS clips (defrule "All Application Traffic by Org Unit Template Selection Logic" ?qo <- (QueryObject (selectApplication true) (orgNetObjectType true) (reportType "pmi_net_user") (reportType "REPORT_TYPE_WINDOW") ) => (set ?go template "AppUserByOU.ftl") ) Is that close to what you're thinking of in JESS? or were you thinking of something different? peter On 4/19/06, Mark Proctor <[hidden email]> wrote: > > In Drools 3.0 that is true of bound field variables, which is the same in > jess. I haven't done it on Columns. If this is the case in Jess I'll look to > add support for it in 3.1 - but I don't see why someone would want to > write a rule like that. > > Mark > Mitch Christensen wrote: > > Wow, that wasn't my understanding at all. > > Going from my (admittedly vague) recollection from Jess, referencing the > same fact-binding variable ('qo' in my case) across conditions means that > the same fact instance must be used across all conditions. > > In other words the value of 'qo' must be equal across the rule. > > I agree that without fact-binding a cross product would result, but I > thought that the fact/pattern binding eliminated this. > > -Mitch > > -----Original Message----- > From: Mark Proctor [mailto:[hidden email] <[hidden email]>] > Sent: Wednesday, April 19, 2006 10:43 AM > To: [hidden email] > Subject: Re: [drools-user] Changes in RC-2 syntax > > Thats a reallly really really bad rule - unless I misunderstand what you > are doing. you are creating a cross product of 16 with that, although we > now remove instance equals cross product. So that means you would have > to assert 4 QueryObjects for this to work. If it was working before > thats because the rule was firing repeatedly for the same object and > doing the same set, so you weren't noticing. > > To understand what I mean try this in RC1 and RC2 in the audit view and > you will understand the difference. > > > Mitch Christensen wrote: > > The following used to work in previous versions (though I'm not sure > > which), > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true) > > qo : QueryObject(selectUser == true) > > qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) > > qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > But when I upgraded to RC-2 in order to get it to fire I needed to change > > it > > to this, > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true, > > selectUser == true, > > orgNetObjectType == > ObjectType.pmi_net_user, > > reportType == > Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > Which is fine, I understand that the latter is completely resolved within > the alpha/pattern network, but what impact will it have on my ability to > define DSL? It seems the former would lend itself to a more > > straightforward > > DSL implementation. > > > > Also, it seems that the former should still be valid, though less > > efficient. > > > > -Mitch > > > > > > > > |
|
|
In reply to this post by Mark Proctor
I just tried the following rule in JESS
(deftemplate transaction (slot accountId) (slot buyPrice) (slot countryCode) (slot currentPrice) (slot cusip) (slot exchange) (slot industryGroupID) (slot industryID) (slot issuer) (slot lastPrice) (slot purchaseDate) (slot sectorID) (slot shares) (slot subIndustryID) (slot total) ) (deftemplate account (slot accountId) (slot cash) (slot fixedIncome) (slot stocks) (slot countryCode) ) (defrule joinrule1 ?tran <- (transaction (accountId ?accid) (exchange "NYSE") ) ?tran <- (transaction (countryCode "US") ) (account (accountId ?accid) ) => (printout t "joinrule1 was fired" ) ) and it produces a join between the first and second CE. Paste the rule into JESS to see what it produces. for the rule compiler to treat the conditions as a linear sequence of alpha nodes, it should be written with only 1 object bindings. In other words (defrule joinrule1 ?tran <- (transaction (accountId ?accid) (exchange "NYSE") (countryCode "US") ) (account (accountId ?accid) ) => (printout t "joinrule1 was fired" ) ) that's how the current drools3 parser works and is correct. to do otherwise is bad practice in my mind. peter On 4/19/06, Mark Proctor <[hidden email]> wrote: > > In Drools 3.0 that is true of bound field variables, which is the same in > jess. I haven't done it on Columns. If this is the case in Jess I'll look to > add support for it in 3.1 - but I don't see why someone would want to > write a rule like that. > > Mark > Mitch Christensen wrote: > > Wow, that wasn't my understanding at all. > > Going from my (admittedly vague) recollection from Jess, referencing the > same fact-binding variable ('qo' in my case) across conditions means that > the same fact instance must be used across all conditions. > > In other words the value of 'qo' must be equal across the rule. > > I agree that without fact-binding a cross product would result, but I > thought that the fact/pattern binding eliminated this. > > -Mitch > > -----Original Message----- > From: Mark Proctor [mailto:[hidden email] <[hidden email]>] > Sent: Wednesday, April 19, 2006 10:43 AM > To: [hidden email] > Subject: Re: [drools-user] Changes in RC-2 syntax > > Thats a reallly really really bad rule - unless I misunderstand what you > are doing. you are creating a cross product of 16 with that, although we > now remove instance equals cross product. So that means you would have > to assert 4 QueryObjects for this to work. If it was working before > thats because the rule was firing repeatedly for the same object and > doing the same set, so you weren't noticing. > > To understand what I mean try this in RC1 and RC2 in the audit view and > you will understand the difference. > > > Mitch Christensen wrote: > > The following used to work in previous versions (though I'm not sure > > which), > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true) > > qo : QueryObject(selectUser == true) > > qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) > > qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > But when I upgraded to RC-2 in order to get it to fire I needed to change > > it > > to this, > > > > rule "All Application Traffic by Org Unit Template Selection Logic" > > when > > qo : QueryObject(selectApplication == true, > > selectUser == true, > > orgNetObjectType == > ObjectType.pmi_net_user, > > reportType == > Constants.REPORT_TYPE_WINDOW) > > then > > qo.setTemplate("AppUserByOU.ftl"); > > end > > > > Which is fine, I understand that the latter is completely resolved within > the alpha/pattern network, but what impact will it have on my ability to > define DSL? It seems the former would lend itself to a more > > straightforward > > DSL implementation. > > > > Also, it seems that the former should still be valid, though less > > efficient. > > > > -Mitch > > > > > > > > |
RE: Changes in RC-2 syntax
|
|
In reply to this post by Mark Proctor
But doesn't it make sense that variable bindings, whether fact or field
exhibit similar behavior, at least from a consistency standpoint? It seems that once a variable is bound it is...well, bound, and shouldn't change after that. I certainly see your point, and did in fact rewrite the rule to eliminate the duplicate fact bindings. Though I can't recall the specifics, I seem to remember relying on this feature in Jess (perhaps something Jess specific?). I'm certainly not arguing the point, you guys definitely know better than I. It's just different than what I am used to. -Mitch -----Original Message----- From: Mark Proctor [mailto:[hidden email]] Sent: Wednesday, April 19, 2006 11:27 AM To: [hidden email] Subject: Re: [drools-user] Changes in RC-2 syntax That is what he was hoping to do, but he thought this was equivalent ?qo <- (QueryObject (selectApplication true) ) ?qo <- (QueryObject (orgNetObjectType true) ) ?qo <- (QueryObject (reportType "pmi_net_user") ) ?qo <- (QueryObject (reportType "REPORT_TYPE_WINDOW") ) So he was hoping taht binding each Fact to the same variable would mean that it always pointed to the same instance. Now I know this is true for field bindings, once you bind it first, no idea if this is true for Fact bindings - seems kinda crazy. Mark Peter Lin wrote: > let me see if I understand the problem correctly. if I were to translate > this to JESS clips > > (defrule "All Application Traffic by Org Unit Template Selection Logic" > ?qo <- (QueryObject > (selectApplication true) > (orgNetObjectType true) > (reportType "pmi_net_user") > (reportType "REPORT_TYPE_WINDOW") > ) > => > (set ?go template "AppUserByOU.ftl") > ) > > Is that close to what you're thinking of in JESS? or were you thinking of > something different? > > peter > > > > On 4/19/06, Mark Proctor <[hidden email]> wrote: > >> In Drools 3.0 that is true of bound field variables, which is the same in >> jess. I haven't done it on Columns. If this is the case in Jess I'll look >> add support for it in 3.1 - but I don't see why someone would want to >> write a rule like that. >> >> Mark >> Mitch Christensen wrote: >> >> Wow, that wasn't my understanding at all. >> >> Going from my (admittedly vague) recollection from Jess, referencing the >> same fact-binding variable ('qo' in my case) across conditions means that >> the same fact instance must be used across all conditions. >> >> In other words the value of 'qo' must be equal across the rule. >> >> I agree that without fact-binding a cross product would result, but I >> thought that the fact/pattern binding eliminated this. >> >> -Mitch >> >> -----Original Message----- >> From: Mark Proctor [mailto:[hidden email] <[hidden email]>] >> Sent: Wednesday, April 19, 2006 10:43 AM >> To: [hidden email] >> Subject: Re: [drools-user] Changes in RC-2 syntax >> >> Thats a reallly really really bad rule - unless I misunderstand what you >> are doing. you are creating a cross product of 16 with that, although we >> now remove instance equals cross product. So that means you would have >> to assert 4 QueryObjects for this to work. If it was working before >> thats because the rule was firing repeatedly for the same object and >> doing the same set, so you weren't noticing. >> >> To understand what I mean try this in RC1 and RC2 in the audit view and >> you will understand the difference. >> >> >> Mitch Christensen wrote: >> >> The following used to work in previous versions (though I'm not sure >> >> which), >> >> >> >> rule "All Application Traffic by Org Unit Template Selection Logic" >> >> when >> >> qo : QueryObject(selectApplication == true) >> >> qo : QueryObject(selectUser == true) >> >> qo : QueryObject(orgNetObjectType == ObjectType.pmi_net_user) >> >> qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW) >> >> then >> >> qo.setTemplate("AppUserByOU.ftl"); >> >> end >> >> >> >> But when I upgraded to RC-2 in order to get it to fire I needed to change >> >> it >> >> to this, >> >> >> >> rule "All Application Traffic by Org Unit Template Selection Logic" >> >> when >> >> qo : QueryObject(selectApplication == true, >> >> selectUser == true, >> >> orgNetObjectType == >> ObjectType.pmi_net_user, >> >> reportType == >> Constants.REPORT_TYPE_WINDOW) >> >> then >> >> qo.setTemplate("AppUserByOU.ftl"); >> >> end >> >> >> >> Which is fine, I understand that the latter is completely resolved within >> the alpha/pattern network, but what impact will it have on my ability to >> define DSL? It seems the former would lend itself to a more >> >> straightforward >> >> DSL implementation. >> >> >> >> Also, it seems that the former should still be valid, though less >> >> efficient. >> >> >> >> -Mitch >> >> >> >> >> >> >> >> >> > > |
Re: Changes in RC-2 syntax
|
In reply to this post by Mark Proctor
Actually I like that. If using the same bound var in Jess means that it is
the one instance, I would love to have that, as it would be VERY handy for DSLs... Something for 3.1? I think it could be an important feature. Can someone confirm or deny Jess' behavior? On 4/20/06, Mark Proctor <[hidden email]> wrote: > > That is what he was hoping to do, but he thought this was equivalent > > ?qo <- (QueryObject > (selectApplication true) ) > ?qo <- (QueryObject > (orgNetObjectType true) ) > ?qo <- (QueryObject > (reportType "pmi_net_user") ) > ?qo <- (QueryObject > (reportType "REPORT_TYPE_WINDOW") ) > > So he was hoping taht binding each Fact to the same variable would mean > that it always pointed to the same instance. Now I know this is true for > field bindings, once you bind it first, no idea if this is true for Fact > bindings - seems kinda crazy. > > Mark > > > Peter Lin wrote: > > let me see if I understand the problem correctly. if I were to translate > > this to JESS clips > > > > (defrule "All Application Traffic by Org Unit Template Selection Logic" > > ?qo <- (QueryObject > > (selectApplication true) > > (orgNetObjectType true) > > (reportType "pmi_net_user") > > (reportType "REPORT_TYPE_WINDOW") > > ) > > => > > (set ?go template "AppUserByOU.ftl") > > ) > > > > Is that close to what you're thinking of in JESS? or were you thinking > of > > something different? > > > > peter > > > > > > > > On 4/19/06, Mark Proctor <[hidden email]> wrote: > > > >> In Drools 3.0 that is true of bound field variables, which is the same > in > >> jess. I haven't done it on Columns. If this is the case in Jess I'll > look to > >> add support for it in 3.1 - but I don't see why someone would want to > >> write a rule like that. > >> > >> Mark > >> Mitch Christensen wrote: > >> > >> Wow, that wasn't my understanding at all. > >> > >> Going from my (admittedly vague) recollection from Jess, referencing > the > >> same fact-binding variable ('qo' in my case) across conditions means > that > >> the same fact instance must be used across all conditions. > >> > >> In other words the value of 'qo' must be equal across the rule. > >> > >> I agree that without fact-binding a cross product would result, but I > >> thought that the fact/pattern binding eliminated this. > >> > >> -Mitch > >> > >> -----Original Message----- > >> From: Mark Proctor [mailto:[hidden email] <[hidden email] > >] > >> Sent: Wednesday, April 19, 2006 10:43 AM > >> To: [hidden email] > >> Subject: Re: [drools-user] Changes in RC-2 syntax > >> > >> Thats a reallly really really bad rule - unless I misunderstand what > you > >> are doing. you are creating a cross product of 16 with that, although > we > >> now remove instance equals cross product. So that means you would have > >> to assert 4 QueryObjects for this to work. If it was working before > >> thats because the rule was firing repeatedly for the same object and > >> doing the same set, so you weren't noticing. > >> > >> To understand what I mean try this in RC1 and RC2 in the audit view and > >> you will understand the difference. > >> > >> > >> Mitch Christensen wrote: > >> > >> The following used to work in previous versions (though I'm not sure > >> > >> which), > >> > >> > >> > >> rule "All Application Traffic by Org Unit Template Selection Logic" > >> > >> when > >> > >> qo : QueryObject(selectApplication == true) > >> > >> qo : QueryObject(selectUser == true) > >> > >> qo : QueryObject(orgNetObjectType == > ObjectType.pmi_net_user) > >> > >> qo : QueryObject(reportType == Constants.REPORT_TYPE_WINDOW > ) > >> > >> then > >> > >> qo.setTemplate("AppUserByOU.ftl"); > >> > >> end > >> > >> > >> > >> But when I upgraded to RC-2 in order to get it to fire I needed to > change > >> > >> it > >> > >> to this, > >> > >> > >> > >> rule "All Application Traffic by Org Unit Template Selection Logic" > >> > >> when > >> > >> qo : QueryObject(selectApplication == true, > >> > >> selectUser == true, > >> > >> orgNetObjectType == > >> ObjectType.pmi_net_user, > >> > >> reportType == > >> Constants.REPORT_TYPE_WINDOW) > >> > >> then > >> > >> qo.setTemplate("AppUserByOU.ftl"); > >> > >> end > >> > >> > >> > >> Which is fine, I understand that the latter is completely resolved > within > >> the alpha/pattern network, but what impact will it have on my ability > to > >> define DSL? It seems the former would lend itself to a more > >> > >> straightforward > >> > >> DSL implementation. > >> > >> > >> > >> Also, it seems that the former should still be valid, though less > >> > >> efficient. > >> > >> > >> > >> -Mitch > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > |
«
Return to Drools: User forum
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |