6:45 p.m.
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
7:10 p.m.
Further investigation has shown me that, with the given LHS scenario,
session.getFactHandle(Object obj)
is capable of giving me the correct fact handle value even for the
facts being passed through a "from".
This leads me to think that the useless FactHandle values returned by
getFactHandles() are due to a bug (and not so by design).
-W
On 02/03/2013, Wolfgang Laun <wolfgang.laun(a)gmail.com> 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
7:15 p.m.
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.
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.
Of course, I agree that the integrity of the WM (and thus of the
universe) is broken,
albeit in a minor way :). 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4350
days inactive
4350
days old
2 comments
2 participants
participants (2)
-
Davide Sottara -
Wolfgang Laun