Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/970
@nickwallen My main concern re: pluggability is for a lot of this stuff,
it's going to be very pretty specific to the fact that (right now) we're using
Lucene stores (and it might be worth renaming some of the base classes to
things like `AbstractLuceneMetaAlertDao` to make that more clear). The entire
denormalization implementation is directly because of the limitations /
strengths of Lucene stores. A store that implements more familiar joins would
be totally different (and probably much, much simpler) than the ES and Solr
impls.
I agree that refactoring is extremely nice to improve testability, but I'm
not sure what the benefit of making things more extensively pluggable (beyond
splitting the DAO up into the Search / Update / subsets + your example of
calculating metascores is good). Are you more interested into breaking things
out into more classes than that, just breaking apart functions more so they're
more easily tested, some combination of both?
I guess the main question is: "Is breaking the meta alert dao into the
various sub functions (Search, Update, etc.) + pulling out the calculate logic
+ at least a refactoring pass for testability a good first step in moving this
forward?" I want to make sure there's at least a clear next step before doing a
lot of adjusting, even if the exact final state might shift a bit.
---
