Here is another way of matching Offers first-in first. It is based on
a linked list connecting new Offers the way they arrive. You'll need
another WME OfferList containing references to the head of the list
and to the last element. An unlinked new Offer is added at the end.
Matching is now done by looking at the "head" field of the OfferList
WME, and a matched Offer is removed from the list. You'll probably
need another field in an Offer to indicate the status (new, unmatched,
matched) so that you don't get cycles in your loop firings.
-W
On Wed, Apr 28, 2010 at 3:43 AM, Andres Corvetto <acorvetto(a)gmail.com> wrote:
Thank you for your answers.
I tried this approach (which yields much more elegant rules), but i'm afraid
it does not perform very well.
If I insert 10000 Offers and then 1 bid, it takes too much time to execute.
If understand correctly it's because of the "not Offer(creationTimestamp <
$ct)" clause in the LHS, which forces a comparison of every matching Offer
against every other Offer.
The motivation for my original post was to find a way of achieving the
results of an accumulator without having to sort all the matching Offers by
creationTimestamp.
Going back to that first approach (using an accumulator), I found that
Drools feeds the accumulator with the matching Offers in reverse order (ie,
newest first, LIFO).
Is this a natural consequence of the way facts are stored in the working
memory or is there a way of changing this behaviour (so that oldest are
feeded first, FIFO)?
Thanks again
- Andres
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
Sent from the Drools - User mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users