I think that my solution inhibits the creation of useless (i.e., to be
removed later) Recommendation facts, which ought to be better than
creating all and removing the superseded ones later (as I think your
latest rule set does).
Expressing preference though data is "cleaner" than using salience.
Consider what happens if the order of preference changes: you'd have
to rewrite rules (salience); I just change the creation of my Superior
facts. Also, I think I need less rules, which is always good. - But
only a benchmark with representative data is decisive.
-W
On 04/10/2012, raffi <christian.koehler(a)s2008.tu-chemnitz.de> wrote:
Hi.
As suspected the way of showing the output was not optimal. I now get the
objects with a query, as you said:
query "recomms"
recomm : Recommendation()
end
And it shows that my currently solution is working in the way it should. My
inserting rules now look like this:
rule "pets"
salience 20
activation-group "categories"
when
$tr : Translog($trpid : pid)
$p : Product(pid == $trpid, $pid : pid, $price : price, $brand :
brand)
$pcat : ProductCategory(pid == $pid, $cid : cid)
$cat : Category(cid == $cid, cname == "pets", $cname : cname)
then
insert(new Recommendation($pid, $price, $brand, $cname));
end
rule "food"
salience 20
activation-group "categories"
when
$tr : Translog($trpid : pid)
$p : Product(pid == $trpid, $pid : pid, $price : price, $brand :
brand)
$pcat : ProductCategory(pid == $pid, $cid : cid)
$cat : Category(cid == $cid, cname == "food", $cname : cname)
not Recommendation(cname == "pets")
then
insert(new Recommendation($pid, $price, $brand, $cname));
end
...
After all transaction data was read in I call the remove rules in a
descending order:
rule "remove everything except pets"
salience 19
when
exists Recommendation(cname == "pets")
$recomm : Recommendation(cname == "food" || cname == "vegetable" ||
cname
== "drinks")
then
retract($recomm);
end
rule "remove everything except food"
salience 18
when
exists Recommendation(cname == "food")
$recomm : Recommendation(cname == "vegetable" || cname ==
"drinks")
then
retract($recomm);
end
...
I think there is space for optimization.
Is there a huge speed advantage in your solution laune in comparison to
mine
(because I have far more rules) in case of lets say 10.000 master data
facts
in working memory?
Thank you
--
View this message in context:
http://drools.46999.n3.nabble.com/mixing-activation-group-and-ruleflow-gr...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users