Fork me on GitHub
#clara
<
2020-10-20
>
schmee13:10:18

what a good approach to ensure that a fact is only inserted once, kind of like a primary key in a DB?

schmee13:10:49

I could have a rule where the RHS literally checks in a DB to see if the key is there, but it seems better to keep as much state as possible in the session?

PB17:10:39

It seems kind of dangerous have side-effects inside of a rule.

nikola15:10:10

What would be the best practice to implement a decision table like that?

nikola15:10:45

At my team a couple of product specialists use Excel for logic like that and I was wondering if I can somehow turn them into Clara rules and use it to make decisions. Has anyone have done something similar in the past?

mikerod16:10:05

@schmee Use an accumulator for the fact you actually want 1 of

mikerod16:10:10

if you have rules that may produce multiples

mikerod16:10:17

make an intermediate fact type to represent the multiple

mikerod16:10:26

then a single acumulator to aggregate it “down to 1”

mikerod16:10:46

this aggregation rule is you explicitly choosing how you want to represent or handle multiple supporting matches

mikerod16:10:14

it’s not always obvious actually - if they happen to have different data associated with them them or something

schmee16:10:51

gotcha, thanks for the tip!

mikerod16:10:11

@nikola.kasev I haven’t attempted anything first-class with tables like that - but you could start by just trying to make rule to represent it and see what patterns may emerge

mikerod16:10:51

I know some traditional rete-based engines - like Drools on the JVM - had some spreadsheet-like decision table functionality built on top to capture the pattern - but underneath was stilll just plain rules