Fork me on GitHub
#clara
<
2017-08-14
>
curtis.shaffer15:08:38

@olivergeorge authorization on the database is something that can be done; certain databases (Oracle is the one that comes to mind) support triggers which you could use to detect changes

curtis.shaffer15:08:12

@hagmonk as far as I can tell, all three of those facts will still be in the session; the 3rd fact insertion does not negate the 2nd fact insertion. the :id field makes me think that you want it to be an update, which is not what is done

zylox15:08:56

@hagmonk What Curtis said. You could use an accumlator to grab the highest valued :milestone fact. or if you are looking for all non negative, you could add a :not constraint. Depends on what you are looking for.

wparker17:08:33

@olivergeorge it might help if you can clarify your question. From Clara’s point of view, it doesn’t matter what the ultimate source of the data it processes is. Note though that if rules do things that depend on ordering you have to be careful since Clara can fire and then retract a rule; the contract when using truth maintenance is that the state of the rules engine works out before fire-rules returns. But if you, say, performed operations on a database in a rule RHS you’d have to be careful about controlling rule ordering with salience etc. Our workflows typically involve something retrieving data, providing the data to Clara, firing the rules, querying the resulting session, and then saving the query results - does that help?