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