Do Items have a UPC? Any reason why you can't insert the Items directly into working memory? Then you could do this:
rule “deal finder” when SearchItem($upc : upc != null) Item(onSale == true, upc == $upc) then Buy stuff end --- On Fri, 8/21/09, Pegram, Macon <zmpeg...@choosehmc.com> wrote: > From: Pegram, Macon <zmpeg...@choosehmc.com> > Subject: [rules-users] Looking for attributes on an element obtained from a > Map > To: "Rules Users List" <rules-users@lists.jboss.org> > Date: Friday, August 21, 2009, 11:47 AM > > > > > > > > > > > > > > > > > > > > > I was > hoping the recent conversation > regarding maps this would come up, but so far it > hasn’t. > > > > > How do I > check for conditions on the > element referenced in the map? > > > > > So given > the following scenario: > > > > > SearchItem > is the item being searched for > by the user > > Item has > the attributes: UPC (String) and > OnSale (Boolean) > > StockRoom > has an attribute of stock which > is Stock = HashMap<String, Item> (key value > is UPC) > > > > > Now > let’s say I want to write a rule > that says, “If the provided Item is in Stock, and on > Sale .. purchase it” > > > > > rule > “deal finder” > > when > > > > SearchItem($upc : upc != null) // see > if a UPC was provided > > > StockRoom($stock : stock) // get a > handle to the stock > > > HashMap (this[$upc] != null) from > $stock // look for the UPC in stock > > Item > (onSale == true) from $item // > Where do I obtain the reference handle that is > $item? > > then > > > // > Buy stuff > > End > > > > > > What > I’m trying to understand syntactically > is how do I obtain a reference handle to the > “Item” found in the > HashMap reference (IE: $item) so that I can check > additional attributes on > that Item. > > > > > I > haven’t found any good examples of > how to do this yet. > > > > > > > > > > > > > From: > rules-users-boun...@lists.jboss.org > [mailto:rules-users-boun...@lists.jboss.org] On > Behalf Of Edson Tirelli > > Sent: Friday, > August 21, 2009 9:16 > AM > > To: Rules > Users List > > Subject: Re: > [rules-users] Maps in > Drools > > > > > > > > > > > 2009/8/20 André Thieme <address.good.until.2009.dec...@justmail.de> > > > Would there not be an addition to the > syntax needed, for the default > > rule language? For mvel it would not require a change I > guess. > > > > > > No, as I mentioned to you, the idea is for the DRL to > remain the same, so that > the rules author does not have to worry about what the IT > guys are doing with > the domain model. So, the rules author would write: > > > > Customer( name == "bob" ) > > > > The IT guy would simply use a configuration to tell the > engine: this object > type uses a map format, that one is a POJO, that other is > an XML entity, etc. > > For instance, if he wants to do that in DRL (he could also > use API, or conf > files), he could do: > > > > declare Customer > > @format( map ) > > end > > > > declare Order > > @format( pojo ) > > end > > > > So, we have a clear distinction between the technical > aspects and the business > aspects of the application. > > > > Your clojure macro would generate always the same DRL code > "Customer( name > == "bob" )", but you said yourself that > clojure is 100% java > compatible, so imagine the enterprise had a domain model > implemented as pojos > already and as part of the new application some new > entities are modeled in > clojure. The macro would generate always the same code, but > you would configure > some entities in the domain as POJOs and other entities as > Maps. > > > > > > > > > > Hmm, but the MVEL syntax can not > magically eliminate the eval. Under > the > > hood the map accesses will still be inside an eval. Marc > confirmed that > > a few days ago. > > MVEL only hides this from the user. This is what I will > also do. > > But under the hood it will become > > > > $a:Map() > > $b:Map() > > eval( $a.get("type") == > "Customer" ) > > eval( $b.get("type") == > "DailyOrders" ) > > > > > > > > Here I think we have other misunderstanding. I will try to > explain, but ideally > you need to learn a bit about the Rete algorithm to see the > whole picture. > There are 2 types of eval(). Inline eval() and top level > eval(). What you wrote > above is a top level eval, meaning it will become a node in > the rete network. > So your example above generates an "execution > plan" (making an > analogy with SQL) that will get all Maps in the working > memory, join them in > tuples size 2, and then test each tuple for the 2 evals. > So, you see why this > will generate C(n,2) partial matches, while C(n,2) as we > know is n!/(n-2)!, > what is really bad for growing "n". > > > > Now, the same thing could be written using inline evals > as: > > > > $a:Map( eval( $a.get("type") == > "Customer" ) ) > > $b:Map( eval( $b.get("type") == > "DailyOrders" ) ) > > > > In this case, the inline eval() will generate an > alpha constraint in the > network, i.e., it will be applied BEFORE the joins. So, > instead of doing all > combinaions possible between all maps as above, it will > first find all Customer > maps and all DailyOrders maps and only after that will make > a join between > them. So you get Customers * DailyOrders partial matches. > The above evals are > semantically equivalent as: > > > > $a:Map( this[ "type" ] == "Customer" ) > > > $b:Map( this[ "type" ] == "DailyOrders" > ) > > > > > > > But currently I am forced to produce this cross > product, as there is no > direct support for Maps yet. > > > > I hope that by the above you see that the problem of the > cross products is not > a problem with Maps support, but rather a question of how > to write better > rules. The same way you can write 2 completely different > SQL queries that > return the same result but one is fast and the other is > completely heavy and > slow, you can also write good rules and really bad rules. > > > > []s > > Edson > > > > > > > > > > > > > > -----Inline Attachment Follows----- > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users