On 24 March 2011 20:03, Joe White <[email protected]> wrote: > Wolfgang I use patterns like that for a data filtering problem and also for > a preferential selection problem. Any time I have two sources of the same > data and I prefer one over the other that pattern allows you to pick the > secondary source when the preferred data doesn’t exist. Also used in cases > where we want to execute a different action in the absence of the second > source. > > > > It also occurs for us when dealing with a list of objects where we have two > sources for the same type of data and we prefer one data source over the > other, but we don’t always get data for the preferred source.. We use your > pattern to make sure the preferred source doesn’t exist before using the > secondary source > > >
So you distinguish "source" by ranges of a numeric property? This is unusual. For your use case I'd expect something like not Data( source == Source.PRIM ) Data( source == Source.SEC, ... ) To clarify, here is the rule logic I posted, written with a redundant constraint in the first pattern. Fact( field >= 10 && field <= 20 ) // if > 20, LHS fails due to "not" not Fact( field > 20 ) Thanks Wolfgang > > > Joe > > > > Here is an example from our code. $ebs is a List<Map>. Mapping to your > example the Map is the fact and the combination of BnftInfoCdoe and > BnftCvgeLevelCode would be the field.: > > > > Map(*this*[BenefitsConsts.BenefitResponseEligibility.BnftInfoCode] == > 'C', > > *this*[BenefitsConsts.BenefitResponseEligibility.BnftCvgeLevelCode] > == 'IND', > > *this*[BenefitsConsts.BenefitResponseEligibility.SvcTypeCode] == > "30", > > *this*[BenefitsConsts.BenefitResponseEligibility.CvgePeriodQlfr] == '25', > > *this*[BenefitsConsts.BenefitResponseEligibility.BnftAmt] *matches* > "0.*") *from* $ebs > > > > *not* (Map(*this*[BenefitsConsts.BenefitResponseEligibility.BnftInfoCode] > == 'C', > > *this*[BenefitsConsts.BenefitResponseEligibility.BnftCvgeLevelCode] > == 'FAM') *from* $ebs) > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Wolfgang Laun > *Sent:* Thursday, March 24, 2011 11:07 AM > *To:* Rules Dev List > > *Subject:* [rules-dev] An odd couple of patterns > > > > Has anybody ever seen a situation where a couple of patterns such as > > > Fact( field >= 10 ) > not Fact( field > 20 ) > > was appropriate? This does not match Facts where field isn't between 10 and > 20, and so it would seem to be the same as > > Fact( field >= 10 && <= 20 ) > > but actually it doesn't match any such Fact whenever any *other* Fact with > field > 20 is around. > > Cheers > Wolfgang > > _______________________________________________ > 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
