The TMS tracks the number of supporting rules for a given fact. When you insert something
you are typically calling “new”, which always means a new identity. If this was done by
identity every local insertion would be a different object, and thus only ever one
So the most common use case for this is with equality. Where as the most common use case
for normal working memory is identity. We made the working memory identity/equality
configurable, as it works the same with the same API. The use case for identity with the
TMS is less common, but would not be impossible to support, but it may require an
alternative api, for it to make sense. It’s not been done, as no one has asked for it
On 27 Jun 2014, at 17:16, mikerod <mjr4184(a)gmail.com> wrote:
I understand that logical insertions in Drools does not insert two
are equal according to their #equals implementation (and associated
I'm basing this off of my own investigation plus the (well written)
However, normal/stated fact assertions only use identity-based equality
checks - by default.
It looks like this can be changed to value-based equality via
I have found some related, old Jiras:
In both cases, Mark Proctor had a final remark, but I wasn't able to
understand what was really decided and why.
One specific comment @ https://issues.jboss.org/browse/JBRULES-266
"logical assertions are always equality based. Stated facts can now use
identity and equality - using your configuration settings.
I have added another configuration setting to dictate how logical over-ride
works. Does it discard the original fact, or turn it into two stated fact
What is the reasoning behind only using the value-based equality for logical
Why is it not configurable as stated fact assertions are?
Also, why is the default behavior of stated fact assertion to be
- I find the inconsistency between the default for normal assertions and the
(only option) for logical assertion to be a bit confusing/inconsistent.
I'm just looking for an understanding the motivation behind these design
I have had a lot of performance issues using, primarily, logical assertions
due to the "no duplicate" checking being done.
Even the stated assertions do still come with a cost of creating the initial
With deeply nested/complex domain objects, the #equals and #hashCode
implementations may be quite expensive when executed many times throughout
This is especially prominent in accumulators that may later accumulate these
objects into collections that then are also subject to this equals/hashCode
I have a related post a while back @
I do not believe it is typical to use complex domain model objects as the
keys to something like a HashMap.
One reason (there are more; especially for mutable objects) would be due to
the performance around having them be hashed and equality checked regularly
map is accessed, modified, etc.
The creation of many FactHandle's has shown up in some of my profiling
performance problems due to this the constructor immediately hashing my
domain model objects.
I think the reason the fact handles use this information is for value-based
equality comparisons - such as the only method used by the Truth Maintenance
System logical assertions.
I would really appreciate more insight into the motivation for not allowing
#equals facts to be logically asserted separately into working memory -
especially since there is a price to pay for the behavior in my case.
View this message in context:
Sent from the Drools: User forum mailing list archive at Nabble.com
rules-users mailing list