Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/970
@nickwallen
Right now those interfaces are basically a marker interface that requires
everything that's needed for a complete DAO set. Prior to some of the Solr
refactorings, it existed as a single DAO to provide a complete set of
functionality to be implemented in order to allow an implementation to be
complete (for some definition of complete) and available to be swapped out via
configuration. Even with the refactoring into multiple interfaces, the
IndexDao and MetaAlertDao still exist to provide some definition of complete.
Getting rid of IndexDao in particular likely has potentially broader
implications because right now that interface ties together the various layers.
Making those changes in a complete and consistent manner is larger than
MetaAlertService, because the SearchServiceImpl and others take an IndexDao
(which could be a regular SolrDao or SolrMetaAlertDao, etc.) in order to allow
regular searches to have meta alert adjustments, e.g. massage the queries to
make sure metaalerts get searched and returned.
Another problem is there's refactoring to existing infrastructure and
patterns around the creation and composition of IndexDaos. In addition,
configuration changes will need to be made (and thought out) without that
interface existing. I'm not sure how large that refactoring is, but I think
changing and testing that is nontrivial enough that it should be a separate PR.
In particular, I'm worried about increasing the scope of an already large
and complicated PR and I'm disinclined to pull that task into this PR without
compelling reasons. If removing those interfaces is a necessity for moving
forward here, I'd like to see that as a PR against the parent feature branch
that we pull into this branch when it's done. I'm happy to help out using this
branch (or a derivative thereof) as a pilot / testing ground for that, but
again I think removing the basic DAO interface itself is outside the scope of
this.
I'd like to know what specific problems we're going to solve that merit
that level of change in this PR. IMO, those problems would need to be pretty
compelling (e.g. we find that reducing the duplication between ES and Solr
necessitates it) to increase the scope that way unless the changes end up being
substantially easier and less impactful than I'd expect.
---
