So I would look at data item X -> Y -> Z and insert X as an item, Y as an item, and Z as an item, with a unique id for the source combination of [X -> Y -> Z]? Hmm.... That does look like an interesting solution.
2009/4/21 Wolfgang Laun <[email protected]> > It seems to me that adding a property "chain" with a unique value for each > chain would solve (part of) the problem since then you could write s.th. > like > X( $chain : chain, foo == whatever ) > Z( chain == $chain, bar == anyval ) > > Or am I way off? > > -W > > 2009/4/21 Tina <[email protected]> > >> Good question, Wolfgang. Our end-users are aware of the structures that >> they've created. So, if they expect data to come in of type X, which may >> have a parent somewhere up the chain of type Z, they'd write a rule looking >> for data with property X.foo and Z.bar that meets certain conditions. >> Effectively, they're writing rules to look for possible combinations of data >> properties known to them. (Note that I expect that I'm not going to be able >> to make great use of Drool's Eclipse plugins or other GUIs to allow them to >> pick fields. I'm expecting to have to extend those plugins to deal with our >> more abstract structures.) >> >> If we only cared about data from type X in our rule, I could simply write >> the rule directly to X, and map its properties directly. But because I also >> care about fields from Z, and that path from X to Z isn't a direct nested >> path, I run into difficulties. >> >> >> >> 2009/4/21 Wolfgang Laun <[email protected]> >> >> One thing that's not clear to me, but essential to a discussion of this >>> problem: How do write (or even define) the rules if you don't know the >>> actual properties the incoming Beans will have? >>> >>> -W >>> >>> 2009/4/21 Tina <[email protected]> >>> >>>> I'm trying to get a handle on whether Drools is the right tool for the >>>> job we have at hand. Based on what I've seen in the documents and >>>> examples, >>>> I believe it could be, but that we're definitely taking a more difficult >>>> path. Interested in thoughts from folks with more experience than me. >>>> >>>> Our project is looking for a solution to let us deal with streaming >>>> data, and determine whether each individual data item meets a rule's >>>> criteria. Each data item implements an interface, but the properties >>>> available on the concrete objects differ wildly. Also, each data item can >>>> be considered to be composed of multiple levels of these data items. One >>>> of >>>> the fields on the interface is a getParent field, which returns the data >>>> item one level up. (In effect, we end up with a singly linked list.) If >>>> X is the object which we have a direct handle to, X.parent = Y, and >>>> Y.parent >>>> = Z, we often want to look at Z.field as part of our rule. I believe that >>>> the quirk here is that, although the objects are JavaBeans, they are >>>> presented as an interface which does not describe the property set of the >>>> bean. Thus, I don't directly know that X's parent is Y, whose parent is of >>>> type Z, which then has a property named 'foo'. (Beans here are essentially >>>> user-defined structures for contributed code, and thus we have no real way >>>> of knowing what properties are on a bean until we receive the bean. When >>>> the users use the beans, they obviously know which bean they're working >>>> with. For us, we're getting it downstream, and that bean could be any of a >>>> dynamically growing variety, also with many different permutations of >>>> structures in the linked list.) >>>> >>>> As a practical matter, the interface has a method getField(String, >>>> String), whihc allows us to access specific fields both in the local bean >>>> and in the beans available up its list. That functionality is accomplished >>>> through some reflection logic. >>>> >>>> I've tried the following approach, but it "smells" wrong: >>>> - Create adapter classes per rule, and, given a data item, insert the >>>> item again, adapted with a bean that gives access to the specific fields. >>>> We believe the # of rules will be 10 or less at any given time in the >>>> operational system. This would require us to query the known rules, and >>>> provide adapter classes for them, which seems completely counter to normal >>>> patterns of use. However, it would allow us to use a bean approach. [Note >>>> that although I've shown that inserting an event again has my desired >>>> effect, I haven't yet figured out how to query the set of rules, and >>>> provide >>>> adapter classes for each rule.] >>>> >>>> I'm also considering a DSL approach, trying to determine if that would >>>> allow me to somehow transform the problem. >>>> >>>> Any insights or feedback would be wonderful. In-house, we don't yet >>>> have a great depth of expertise with Drools, so I'm interested in tapping a >>>> broader pool of knowledge and experience. I've only got access to Drools 4 >>>> in my environment. I can try alternate approaches in Drools 5 at home, but >>>> can't use that solution as yet for our problem space. >>>> >>>> - Tina >>>> _______________________________________________ >>>> rules-users mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> _______________________________________________ >> rules-users mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
