Forall Conditional Element
by Edson Tirelli
All,
JBRULES-218: http://jira.jboss.com/jira/browse/JBRULES-218 adding
support to the "forall" conditional element is commited into trunk.
You all are welcome to try. Documentation is still pending but
follows a quick walkthrough:
Syntax:
forall( BasePattern([constraints]*)[,] [AdditionalPattern([constraints])
[,]]* )
Example:
forall( Person( $likes: likes ),
Cheese( type == $likes ) )
The above statement can be translated to: "for all Person facts, there
must be a Cheese fact whose type is the one the person likes".
In other words, a forall is translated to:
not( BasePattern(...) and not( AdditionalPattern(...) and
AdditionalPattern(...) ... ) )
So you can make sure that all charges to a credit card have
corresponding charge type and issueing store:
forall( Charge( $type: type, $issuer: issuer ),
ChargeType( type == $type ),
Store( name == $issuer ) )
This is equivalent to (but much cleaner to write):
not( Charge( $type: type, $issuer: issuer ) and
not( ChargeType( type == $type ) and
Store( name == $issuer ) ) )
Let me know if you have any question or find any problem.
Thanks,
[]s
Edson
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
18 years, 11 months
Nesting of Conditional Elements and Conjunctive Negations
by Edson Tirelli
All,
As you may be aware, JBoss Rules 3.0.x does not support nesting of
elements inside a NOT (Conjunctive Negations) or EXISTS node. Also, the
nesting of ANDs and ORs is not totally consistent for all cases.
We spent the last few weeks working on the full support to arbitrary
conditional element nesting. It means now you will be able to nest
whatever CE you want inside any other CE. This is an important step in
supporting "forall" and improving "accumulate" for Event Stream Processing.
For those of you curious to try it, code is commited. Just checkout
from trunk, build and try it. As the change to support this feature was
a big one, there may eventually be issues to fix, so if you find one,
please report in order to help us have it ready for release.
For one example of things you can do, pretend there is a business
rule that says:
"All VIP guests must have Caviar, Cheese and his prefered champagne
served in his table".
The above rule can be easily implemented now in the following way:
rule "Guest's dinner"
when
$gc : GuestCategory( type == "VIP" )
not ( Guest( category = $gc, $table : table, $champ :
preferedChampagne )
not( Caviar( table == $table ) and
Cheese( table == $table ) and
Champagne( type == $champ, table == $table ) ) )
then
results.add("All VIP guests are served");
end
I will add "forall" now, that is just syntax sugar for the above
structure.
[]s
Edson
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
18 years, 12 months
Package configuration file design thoughts
by Michael Neale
Guys,
In the repository, and also in general (ie normal IDE/text files) we are
going to allow rules to be in individual files, and then have a deployment
tool collect them all up, compile etc... (of course current DRL will still
apply as it does now).
For this to work, they will all be (for now) in the one folder - and there
will be some overarching "package configuration" that sets the name space,
imports, globals etc (all the stuff you see at the top of a drl now).
So my question:
*should this config file just be a plain test file - line based stuff just
like you see now at the top of the .drl file?
* Or, should we have some more controlled XML or flat format that has more
meta data in it (from the repository, optionally). In any case, a nice
Eclipse Form based UI can "help" with the package config (importing classes
etc), but at the end of the day, it has to be friendly for hand editing
text.
* or multiple files for different "parts" of the config (imports in one,
globals in another etc).
(and it will of course be synced to the repository where applicable).
Thoughts anyone?
Michael.
18 years, 12 months
Better way to use And and Or
by rules-dev＠lists.jboss.org
Hi,
I am using Drools 3.0
For below rule
RCVRCOUNTRY == IRAQ,IRAN
SNDRCOUNTRY == US,CAN,UK
AMOUNT > 3000
i have to compile the drl with this
m: (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "US", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "UK", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "CAN", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "US", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "UK", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "CAN", AMOUNT >
"3000"))
Is there any other easier / better way to express this as a valid DRL? using
|
--
View this message in context: http://www.nabble.com/Better-way-to-use-And-and-Or-tf2940808.html#a8222646
Sent from the drools - dev mailing list archive at Nabble.com.
19 years
Issues with ANd and Or operator
by rules-dev＠lists.jboss.org
Hi,
i am using drools 3.0
For below rule
RCVRCOUNTRY == IRAQ,IRAN
SNDRCOUNTRY == US,CAN,UK
AMOUNT > 3000
i have to compile the drl with this
m: (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "US", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "UK", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "CAN", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "US", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "UK", AMOUNT >
"3000"))
m: (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "CAN", AMOUNT >
"3000"))
Is there any other easier / better way to express this as a valid DRL? using
|
--
View this message in context: http://www.nabble.com/Issues-with-ANd-and-Or-operator-tf2940784.html#a822...
Sent from the drools - dev mailing list archive at Nabble.com.
19 years
Problem with And and Or operator
by garima015
Hi,
For below rule
RCVRCOUNTRY == IRAQ,IRAN
SNDRCOUNTRY == US,CAN,UK
AMOUNT > 3000
i have to compile the drl with this
m: (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "US", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "UK", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "CAN", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "US", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "UK", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "CAN", AMOUNT >
"3000"))
Is there any other easier / better way to express this as a valid DRL?
--
View this message in context: http://www.nabble.com/Problem-with-And-and-Or-operator-tf2940364.html#a82...
Sent from the drools - dev mailing list archive at Nabble.com.
19 years
Issues in combining AND and OR
by garima015
Hi,
For below rule
RCVRCOUNTRY == IRAQ,IRAN
SNDRCOUNTRY == US,CAN,UK
AMOUNT > 3000
currently gets translated to the below LHS
m: (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "US", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "UK", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAQ", SNDRCOUNTRY == "CAN", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "US", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "UK", AMOUNT >
"3000"))
or (TransactionBean(RCVRCOUNTRY == "IRAN", SNDRCOUNTRY == "CAN", AMOUNT >
"3000"))
Is there any other easier / better way to express this as a valid DRL?
--
View this message in context: http://www.nabble.com/Issues-in-combining-AND-and-OR-tf2940077.html#a8220292
Sent from the drools - dev mailing list archive at Nabble.com.
19 years
MVEL Integration
by Mark Proctor
I have 'from' working with MVEL now, I'll commit the code a little later.
Mark
19 years
AvailableVariables
by Mark Proctor
Edson,
You deleted AvailableVariables but much of the code you refactored still
relies on that?
Mark
19 years
[drools] Welcome to the new JBoss Rules Mailing list
by JBoss IT
Welcome to the new JBoss Rules Mailing list. We are moving our lists
to our own list server (lists.jboss.org); the web based list services
GMane and Nabble have also migrated with the new lists, maintaining
existing archives. This move was intended to be somewhat invisible, but
a problem with our process caused a number of "unsubscribe" messages to
be sent. If you are getting this welcome message, you are subscribed to
the new list.
The lists migrations are as follows:
announce(a)drools.codehaus.org -> rules-announce(a)lists.jboss.org
dev(a)drools.codehaus.org -> rules-dev(a)lists.jboss.org
user(a)drools.codehaus.org -> rules-users(a)lists.jboss.org
You can find detailed info for each mailing list here:
rules-announce : https://lists.jboss.org/mailman/listinfo/rules-announce
rules-dev : https://lists.jboss.org/mailman/listinfo/rules-dev
rules-users : https://lists.jboss.org/mailman/listinfo/rules-users
To post to this list, send your email to:
rules-dev(a)lists.jboss.org
General information about the mailing list is at:
https://lists.jboss.org/mailman/listinfo/rules-dev
If you ever want to unsubscribe or change your options (e.g., switch to
or from digest mode, change your password, etc.), visit your
subscription page at:
https://lists.jboss.org/mailman/options/rules-dev/
You can also make such adjustments via email by sending a message to:
rules-dev-request(a)lists.jboss.org
With the word `help' in the subject or body (don't include the quotes),
and you will get back a message with instructions.
Thanks and welcome to the new list!
postmaster(a)lists.jboss.org
19 years
