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
