It could be very usefull, specially if you are using a very big number
of facts - that's my problem, actually (30 000 facts and more).
The 'special template' stuff, (cf Burke message) could be a good
approach, but that drives to something like overloading every access
method of the Fact class in the engine (from getSlotValue to
getStaticSlotValue). Otherwise, extending Fact class from something
else than ValueVector (a database access class) is another way.
The big issue is how to manage new facts: you have to be 'signaled' by
the databse when a new facts has been inserted - or modified -.
Considering you are instanciating an engine to work on a set of facts,
may be that's not a problem for you, but it's a static approach to
this problem. The database is just another way to store these facts
without experiencing memory boudary problems (java -mx1024M -ms1024M
jess/Main is not always a solution :))
Another boring point is the way the engine is working : Rules are
activated by Facts, and with a very big database, it could be very
time -and memory - consuming (you browse the whole database to
activate each eligible rule, which mean that you store this
information ( rules (R1, R2, ... Rm) have been activated by fact (f1,
f2, ..., fn)) in memory. very very costly :(
The more you have facts, the more it costs.
Anyway, I buy the Idea.
Emmanuel Lécharny
tel : 01 71 00 68 00
www.imediation.com
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
