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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] <[EMAIL PROTECTED]>]
Sent: Wednesday, April 19, 2006 10:43 AM
To: [email protected]
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
