Hi Sotty, thanks for the reply.
On 02/03/2013, Davide Sottara <dso...@gmail.com> wrote: > When **from** is used, there is no guarantee that the objects > are part of the working memory - actually it is expected that they aren't, > otherwise a memberOf constraint would have probably been used. Possibly, but not necessarily. Again, all Ones and Twos are facts; but now there is a subtle difference between One( $list: listOfTwos ) Two(...) from $list and One( $list: listOfTwos ) Two( this memberOf $list ) because the former avoids looping when Two is updated on the RHS. (In my particular case, I can't use the field to be changed in a constraint to avoid looping. And I dislike of the attribute no-loop.) > Tentatively looking up a possibly-but-unlikely-existing fact handle for > each object would > have impacted performance negatively, so it was decided that **from** > would **always** create handles on the fly. Well, here's where I'm well and truly miffed. It's all right if the engine needs fact handles created on the fly for its happiness, but it shouldn't give them to me, at least not without a clear indication that they aren't "the real thing". And not documenting such possible pitfalls is downright mean. > Of course, I agree that the integrity of the WM (and thus of the > universe) is broken, > albeit in a minor way :). It has cost me a hundred times the time that it would have taken to add a warning to the Javadoc. Cheers Wolfgang > We couldn't yet find a use case where this > inconsistency > would cause major issues. > I'd move the discussion to the drools-dev list anyway, if a major > problem - or > an efficient solution - could be proposed. > Best > Davide > > > On 03/02/2013 10:45 AM, Wolfgang Laun wrote: >> Given a >> org.drools.event.rule.BeforeActivationFiredEvent, >> method getActivation() returns a >> org.drools.runtime.rule.Activation >> and its method getFactHandles() is documented to return a >> List<FactHandle>. >> >> It should be possible to retrieve the fact object using >> session.getObject( factHandle ), and this succeeds in many instances, >> but not reliably (5.5.0-Final). >> >> Given facts of types One and Two a rule like >> One( $list: listOFTwos ) >> Two(...) from $list >> I find that Two facts, when matched via from, are not reported with >> the proper fact handle, i.e., the one returned from the insert. >> >> What's the point in reporting fact handles that can't be used to >> retrieve a fact object? >> >> If I want to obtain all facts that participate in an activation, is >> method Activation.getObjects() more (and fully) reliable? >> >> -W >> _______________________________________________ >> rules-users mailing list >> rules-us...@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > _______________________________________________ > rules-users mailing list > rules-us...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
