Cheers,
Leo.
On Mon, Sep 20, 2010 at 5:14 PM, Mark Proctor <[email protected]
<mailto:[email protected]>> wrote:
On 20/09/2010 15:53, Leonardo Gomes wrote:
I think I wasn't quite clear in my last email, so let me try to
reformulate it:
I also gave it a try to try to do what you suggested here
(http://blog.athico.com/2010/09/lazily-enabled-truth-maintenace.html),
Mark, and couldn't make it work due to the following situation:
1) Current code seems to rely on the equality map to know that a
logical insert (insertLogical) for an object that has already
been regularly inserted (insert) should be ignored;
You would need to lazily maintain an equality map. When the first
logical insertion is done we will have to first populate that map
from the Object Type Node set of FactHandles.
In the "insert" one of the first lines is:
ObjectTypeConf typeConf =
this.typeConfReg.getObjectTypeConf( this.entryPoint,
object );
So we get the ObjectTypeConf before we do anything with the object
itself, and we can check if TMS is being maintained for that
Object Type.
2) If I apply the modifications that you suggested, from what I
understood, things would start to be put in the equality map only
when a logical insert is issued;
*Problem*: How would I handle the situation described in item 1,
if I don't have anything in the equality map at the moment a
logical insert comes in and I have to "lazily activate" TMS?
final Rete source = this.ruleBase.getRete();
ClassObjectType cot = new ClassObjectType( MyClass.class );
Map<ObjectType, ObjectTypeNode> map = source.getObjectTypeNodes(
EntryPoint.DEFAULT );
ObjectTypeNode node = map.get( cot );
final ObjectHashSet memory = (ObjectHashSet)
workingMemory.getNodeMemory( node );
That "memory" is the set of currently asserted objects for that
OTN. You can now iterate that and populate the equality hash map.
This is a one off as the flag will be set on the ObjectTypeConf
from then on and all objects will be added to the equality map at
the point of insertion.
Does that help? All the information is there, you should have to
know how to retrieve it :) We don't currently maintain TMS for
anything other than the default entry point. Although I think that
was a mistake and we will probably move all entrypoints to work
with same, but for now you can ignore that and just focus on the
default.
Btw this should not be confused with "equality" mode where the
equality map has to be maintained by default from the start. Some
would argue that a rule engine should only under work and
understand on the bases of equality and thus all users must
implement hashcode and equals correctly...
--
Moreover, I'm willing to attempt to implement the left and right
un-linking and tried to start with this easier task to start to
get familiar with drools-core. I already read the article you
linked and your article. Would you have any document with an
overview of the way drools implements rete?
not really no, Rete has already well documented in a number of
papers. The best thing to do is get onto irc and talk directly to
edson and I and we can walk you through classes.
http://www.jboss.org/drools/irc.html
Mark
Thanks in advance!
Cheers,
Leo.
On Sat, Sep 18, 2010 at 3:49 AM, Leonardo Gomes
<[email protected] <mailto:[email protected]>>
wrote:
if you look at the AbstractWorkingMemory insert method
you'll see one argument is whether it's a logical
insertion or not. You'll also see it check the global
maintainTMS configuration and also retrieve the
ObjectTypeConf. So between those things someone should be
able to get it working.
Today, it enters a block where it operates on the equality
map and also creates a default handle based on that TMS
global option and *regardless* of whether it's a logical insert.
If I'm *not* putting things in the equality map for regular
inserts, when a logical insert comes in, but there were
already stated inserts, how will I know that? I would create
a new handle for the logical insert and do the
tms.addLogicalDependency(...), even tough there were regular
inserts before and this seems to be a wrong behaviour.
Apparently, today, you can disable TMS and still use logical
inserts in your drl, what, I believe, will lead to
inconsistent behaviour, but you're at your own risk.
Ideas? I feel that I missed something :)
Cheers,
Leo.
P.S.: I reached the conclusions above based on the fact that
LogicalAssertionTest started failing after I did the changes
you suggested.
On Wed, Sep 15, 2010 at 3:47 PM, Mark Proctor
<[email protected] <mailto:[email protected]>> wrote:
On 15/09/2010 14:35, Michael Anstis wrote:
Is this in drools-core; or drools-compiler?
Whilst not undertaking to do the work; have a purpose to
nose through the code makes understanding easier.
It's all in DroolsCore.
It's a 5 minute hack for me and then 15 minute unit
writing test. But I thought I'd write it up in a hope to
bring someone else into the fold, we need more help
writting the core engine someone else out there must want
to work on current edge engine design :)
if you look at the AbstractWorkingMemory insert method
you'll see one argument is whether it's a logical
insertion or not. You'll also see it check the global
maintainTMS configuration and also retrieve the
ObjectTypeConf. So between those things someone should be
able to get it working.
Mark
On 14 September 2010 16:47, Mark Proctor
<[email protected] <mailto:[email protected]>>
wrote:
Here is another project proposal, this time simpler.
I think this one has Wolfgang's name on it ;)
http://blog.athico.com/2010/09/lazily-enabled-truth-maintenace.html
Three weeks ago I posted the project idea for "Left
and Right Unlinking"
<http://blog.athico.com/2010/08/left-and-right-unlinking-community.html>.
So far there are no takers, so if you are interested
let me know :)
In the meantime I tried to think of a simpler
enhancement that we would like to see done.
At the moment Drools has a user setting
"MaintainTMSOption" which can be true or false. It's
a small optimisation that when turned off avoids
using the equality hashmap that is maintained for
all inserted objects.
It would be a much better idea to remove this
configuration setting, thus simplifying things for
end users and have TMS lazily enabled on demand.
For each object type there is an "ObjectTypeConf"
configuration object that is retrieved every time a
working memory action, such as insert, is executed.
The enabledTMS boolean should be moved there, so
there is one per object type, by default it is false.
When a working memory action occurs, like insert, it
retrieved the ObjectTypeConf and checks the
maintainTms boolean there, instead of the current
engine scoped configuration. When a logical
insertion occurs and the ObjectTypeConf is retrieved
if maintainTms is false it sets the value to true
and then iterates the associated ObjectTypeNode
memory lazily adding all the objects to the TMS
equality map. From then on for that ObjectType all
inserted objects are added to that equality map.
With this you now have the advantage of TMS being
laziy enabled, so the minor hashmap operation is no
longer used and likewise a small memory saving from
not populating the map. There is a further advantage
that this is now fine grained and when enabled only
impacts for that specific object type.
A further enhancement could use a int counter,
instead of a boolean. Each logical insertion for
that object type increases the counter, each
retraction decreases the counter; even if
automatically retracted if the truth is broken for
that logical assertion. When the counter reaches
zero, TMS for that OTN can be disabled. We do not
however remove the objects from the equality map, as
this would cause "churn" if TMS is continuously
enabled and disabled. Instead when TMS is disabled
record the current fact counter id. Then if TMS is
disabled on a retraction but there is a counter id,
we can check that counter id to see if the fact is
prior to TMS being disabled and thus would need to
be retracted from the equality map.
_______________________________________________
rules-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
