Doh! Thanks Greg, i didn't realize it was on dev. Yes, there should be joins if there are multiple Facts. I am used to people here just asserting one object and reasoning over it; because you know, rule engines aren't good at handling many facts ;)
On Tue, Feb 24, 2009 at 1:34 PM, Greg Barton <[email protected]> wrote: > David, please don't take this to be picking on you, but the rule you wrote > wasn't quite correct. :) > > when > $f : Fact() > Detail(fact == $f, name == "END_SET", value == true) > Detail(fact == $f, name == "SET", value = 1) > Detail(fact == $f, name == "PLAYER1_SCORE", $score1 : value) > Detail(fact == $f, name == "PLAYER2_SCORE', value < $score1) > then > ... > end > > Match the Details to their parent Fact. I just want to make sure the newb > doesn't get a combinatorial explosion and run screaming. :) > > And, not picking on both of you, but this should be on rules-users and not > rules-dev. > > --- On Tue, 2/24/09, David Sinclair <[email protected]> > wrote: > > > From: David Sinclair <[email protected]> > > Subject: Re: [rules-dev] Dealing with null pointer exceptions thrown by > parsing rules > > To: "Rules Dev List" <[email protected]> > > Date: Tuesday, February 24, 2009, 12:13 PM > > Alex, please don't take this to be picking on you; this > > is more a post to > > everyone whom reads these forums. > > > > You are not writing procedural, object-oriented, or > > functional code. You are > > writing rules to look for patterns of objects. If > > everything is done in an > > eval you are losing the majority of the benefits of using a > > rule engine, e.g > > node sharing, indexing, etc. Flesh out your object model. > > Assert all of your > > objects into Working Memory. This will allow you to reason > > over anything > > without using evals. > > > > OK -- rant off -- > > > > Alex, you may want to try and refactor your model to be > > more "rules > > friendly". That way your could write rules more like > > the following. > > > > when > > $f : Fact() > > Detail(name == "END_SET", value == true) > > Detail(name == "SET", value = 1) > > Detail(name == "PLAYER1_SCORE", $score1 : > > value) > > Detail(name == "PLAYER2_SCORE', value < > > $score1) > > > > On Tue, Feb 24, 2009 at 12:39 PM, Zevenbergen, Alex < > > [email protected]> wrote: > > > > > Thanks for replying. > > > > > > > > > > > > rule "Player 1 wins first set " > > > > > > when > > > > > > $f : Fact() > > > > > > eval > > ($f.getDetails().get("END_SET").toString() == > > "true" && > > Integer.valueOf($f.getDetails().get("SET").toString()) > > > == 1 && > > Integer.valueOf($f.getDetails().get("PLAYER1_SCORE").toString()) > > > > > > > > Integer.valueOf($f.getDetails().get("PLAYER2_SCORE").toString())) > > > > > > then > > > > > > //then settle selection; > > > > > > end > > > > > > > > > > > > > > > > > > this rules runs perfectly as long as the hashmap > > contained in the ‘fact’ > > > object has all the required keys and their values are > > not null. For the time > > > being I have just changed any null values to a value > > of ‘DEFAULT’ but it > > > would be preferable to be able to look for > > f.getDetails().get("END_SET") (for > > > example) knowing that the engine that sent it might > > not be in an end_set > > > state so may not have added that key. > > > > > > > > > > > > That example is very basic but as I create more rules > > for more sports it > > > could become very cumbersome to have to ensure that > > every key referenced in > > > the rules is in the hashmap each time! > > > > > > > > > > > > Alex > > > ------------------------------ > > > > > > *From:* [email protected] [mailto: > > > [email protected]] *On Behalf Of > > *David Sinclair > > > *Sent:* 24 February 2009 17:27 > > > *To:* Rules Dev List > > > *Subject:* Re: [rules-dev] Dealing with null pointer > > exceptions thrown by > > > parsing rules > > > > > > > > > > > > I understand what you are saying Alex, but could you > > post an example rule > > > to see exactly how you are doing it? It may be that > > you could simply rewrite > > > the rule so you don't get the NPE. > > > > > > On Tue, Feb 24, 2009 at 4:24 AM, Zevenbergen, Alex > > < > > > [email protected]> wrote: > > > > > > Hi all, > > > > > > > > > > > > I have started writing my rules packages and so have > > had a decent amount of > > > success. However all my rules are based on value pairs > > from a hashmap object > > > that is contained within my fact object. This approach > > works fine if the > > > parameter the rule is looking for is in the map and > > has a value. > > > > > > > > > > > > But I will need to be able to pass null values to the > > rules (and expect > > > them to just not fire any rule that looks for that > > param), however this > > > always throws a null pointer exception. > > > > > > > > > > > > So my question is: Is there any mechanism to deal with > > this in drools. > > > > > > > > > > > > Simply setting all nulls to a default value isn’t > > preferable in this > > > situation as the app is going to be used by several > > different sources and > > > has to be able to take in many different types of > > info. > > > > > > > > > > > > Thanking you, > > > > > > > > > > > > Alex > > > > > > > > > > > ________________________________________________________________________ > > > Privileged, confidential and/or copyright information > > may be contained in > > > this communication. This e-mail and any files > > transmitted with it are > > > confidential and intended solely for the use of the > > individual or entity to > > > whom they are addressed. If you are not the intended > > addressee, you may not > > > copy, forward, disclose or otherwise use this e-mail > > or any part of it in > > > any way whatsoever. To do so is prohibited and may be > > unlawful. If you have > > > received this email in error > > > please notify the sender immediately. > > > > > > Paddy Power PLC may monitor the content of e-mail sent > > and received for the > > > purpose of ensuring compliance with its policies and > > procedures. > > > > > > Paddy Power plc, Airton House, Airton Road, Tallaght, > > Dublin 24 Registered > > > in Ireland: 16956 > > > > > ________________________________________________________________________ > > > > > > > > > _______________________________________________ > > > rules-dev mailing list > > > [email protected] > > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > > > > > > > > > ________________________________________________________________________ > > > Privileged, confidential and/or copyright information > > may be contained in > > > this communication. This e-mail and any files > > transmitted with it are > > > confidential and intended solely for the use of the > > individual or entity to > > > whom they are addressed. If you are not the intended > > addressee, you may not > > > copy, forward, disclose or otherwise use this e-mail > > or any part of it in > > > any way whatsoever. To do so is prohibited and may be > > unlawful. If you have > > > received this email in error > > > please notify the sender immediately. > > > > > > Paddy Power PLC may monitor the content of e-mail sent > > and received for the > > > purpose of ensuring compliance with its policies and > > procedures. > > > > > > Paddy Power plc, Airton House, Airton Road, Tallaght, > > Dublin 24 Registered > > > in Ireland: 16956 > > > > > ________________________________________________________________________ > > > > > > _______________________________________________ > > > rules-dev mailing list > > > [email protected] > > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > > > _______________________________________________ > > rules-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
