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 <[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
>
>
>
>
>
>
>
>
