Vincent Legendre wrote
And I did not see all pending posts ...
By reading them, there is another fact that lead to "don't use drools".
You said that you query a distant DB. So, if you write rules to filter
your data, you will have first to get ALL data from your distant DB, add
ALL data in the drools WM, and only then fire rules on them to filter the
data and get only a subset of them.
To me (my opinion), it is an anti-pattern. Filtering a large amount of
data and return only a subset of them is the database job.
The filtering options provided by the remote databases (most of them are
exposed as REST APIs) are "limited". I uses these options whenever I can to
filter data at the source. However, sometimes it's not possible to filter
everything at the source. In such cases I don't have any other option but to
get all the data and then apply my filters "locally."
Vincent Legendre wrote
Oh, yes, you intend to do complex rules that cannot be set as SQL like
syntax ...
You should think of cutting you system in two, by making each tool doing
what it is designed for :
- use SQL like for basic filtering, by sending the query to the distant
DB and thus getting ONLY the data needed
- make drools running of this subset of data to implement more complex
things
Now as discussed below, I can apply "simple" filters by using a in-memory
database (or inserting the data into a SQL database and then using SQL
queries) OR load everything into a WM and then apply these "dynamic" rules.
I think both approaches can work, I just need to figure out the tradeoffs.
Thanks again !
--
View this message in context:
http://drools.46999.n3.nabble.com/Is-there-a-faster-way-of-doing-this-in-...
Sent from the Drools: User forum mailing list archive at
Nabble.com.