Hello-
It appears that you are trying to map the contents of the database into
the world of facts within JESS. This may not be what you are really
looking for.
To do this one-to-one mapping of an RDBMS to JESS, you would need to
intially dump a table as facts and use triggers in the database to assert
and modify facts to keep the database and JESS in sync. To me, this
defeats the purpose of using either JESS or the RDBMS, since you are
trying to map the functionalities of each onto the other.
I would approach the problem by iterating queries on the database. The
results returned could then be asserted as facts which may in turn update
the database with appropriate SQL statements.
It is important to realize the nature of JESS is very much like an engine.
Engines perform work through a cycle. If you can break up the work you
need to be done into a cycle or combination of cycles, then JESS readily
applies. What happens within a particular cycle is undefined with respect
to the order of events, but at the end of the cycle, you know the state
of the system and that some work has been done.
Using a RDBMS allows data to be collected asynchronously in a
well-understood and independent fashion (with transactions and such). To
hook up a production system like JESS to an RDBMS, I think the best way is
to force the use of rules that provide for SELECT and UPDATE cycles.
In your case, where you are looking for a triggering event, I think you
should simply write some specific SELECT queries that return rows that
match the event. Assert the rows as facts and pump the engine. The
engine's rules may then execute UPDATE statements that modify the
database, and when all is done, another cycle is started by having a rule
which identifies the cycle is over.
Unfortunately, I do not think there really is a general solution to this
problem, but there does seem to be this simple pattern to apply.
-Dave Barnett
On Thu, 21 Oct 1999 [EMAIL PROTECTED] wrote:
> Hello list!
>
> I have a question concerning something like "persistent facts"...
>
> I deal with problems where I have to reason about states (stored
> persistently in relational databases) and events (e.g. insert, update, and
> delete events in a database). I can subscribe to the events and then
> actively assert a corresponding "event fact". The question is how to
> efficiently deal with "state facts" corresponding to relational tuples.
>
> A relation corresponds to a JESS template defining an unordered fact:
>
> (deftemplate <relation-name>
> (slot <column-1> ...)
> ...
> (slot <column-n> ...)
> )
>
> Each tuple corresponds to one fact, e.g.:
>
> (<relation-name> (<column-1> <val-1>) ... (<column-n> <val-n>)).
>
> How can I use these "state facts" in JESS rules
> - elegantly (yes, I do like "beautiful" code ;-))
> - in a uniform fashion (rendering itself to generation mechanisms)
> - on-demand (without prior "bulk assertion")
>
> It would be nice to be able to write a rule like the following:
>
> (defrule myrule
> (some-triggering-event (key ?val) ...)
> (<relation-name> (key ?val) (<column-1> <val-1>) ... (<column-n>
> <val-n>))
> =>
> (assert (some-other-fact (key ?val) (<column-1> <val-1>) ... (column-n>
> <val-n>)))
> )
>
> What would be the best way to solve this problem? I think a good solution
> could be of very general use...
>
> Greetings
>
> Thomas Barnekow
>
> ________________________________
>
> Dipl.-Inform. Thomas Barnekow
> Fraunhofer IAO, Competence Center Software Technology
>
> mail:
> Nobelstra�e 12, D-70569 Stuttgart, Germany
> phone:
> +49 (0) 711 / 970 - 2346
> fax:
> +49 (0) 711 / 970 - 2300
> email:
> [EMAIL PROTECTED]
> web:
> http://www.swt.iao.fhg.de
>
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
