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.<br>
<br><div class="gmail_quote">2009/4/21 Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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 <a href="http://s.th" target="_blank">s.th</a>. like<br> X( $chain : chain, foo == whatever )<br>
Z( chain == $chain, bar == anyval )<br><br>Or am I way off?<div><div></div><div class="h5"><br>-W<br><br><div class="gmail_quote">2009/4/21 Tina <span dir="ltr"><<a href="mailto:colemanserious@gmail.com" target="_blank">colemanserious@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.) <br>
<br>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. <br>
<br> <br><br><div class="gmail_quote">2009/4/21 Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>></span><div><div></div><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?<br><br>-W<br><br><div class="gmail_quote">
2009/4/21 Tina <span dir="ltr"><<a href="mailto:colemanserious@gmail.com" target="_blank">colemanserious@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>
<font size="2">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.<br>
<br>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. </font><font size="2">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.) </font><font size="2">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.)<br>
<br></font><font size="2">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. <br><br>I've tried the following approach, but it "smells" wrong:<br>
- 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.]<br>
</font><br>I'm also considering a DSL approach, trying to determine if that would allow me to somehow transform the problem.<br><br>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.<br>
<font color="#888888">
<font color="#888888"><br>- Tina</font>
</font><br></div></div>_______________________________________________<br>
rules-users mailing list<div><br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
</div><a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div><br>
<br>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div></div></div><br>
<br>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div><br>