[rules-dev] [rules-users] Can't obtain object from a FactHandle

Wolfgang Laun wolfgang.laun at gmail.com
Sat Mar 2 14:30:12 EST 2013


Hi Sotty,

thanks for the reply.

On 02/03/2013, Davide Sottara <dsotty at 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-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>


More information about the rules-dev mailing list