Github user justinleet commented on the issue:
    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 
    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.


Reply via email to