[
https://issues.apache.org/jira/browse/METRON-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080939#comment-16080939
]
ASF GitHub Bot commented on METRON-1022:
----------------------------------------
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/636
@ottobackwards just created a discuss thread on the general approach here.
@cestella you're absolutely correct. We need a way for solr and ES to
coexist. A precedent has already been set in our indexing module but just want
to throw another suggestion out there. The downside of having separate modules
that extend a common module is that automated deployment through Ambari MPack
is more complex. In fact, the current MPack doesn't support this right now.
Ideally we could leverage Spring to easily swap out the implementation at
runtime but we would need both Solr and ES classes available on the classpath.
Would it be possible to add lucene classes (and possibly others) to the list of
shaded classes in the elasticsearch-shaded module and create a similar module
for Solr? Or are there challenges I'm not thinking of and/or would it make
things more confusing having different strategies in different parts of Metron?
> Elasticsearch REST endpoint
> ---------------------------
>
> Key: METRON-1022
> URL: https://issues.apache.org/jira/browse/METRON-1022
> Project: Metron
> Issue Type: New Feature
> Reporter: Ryan Merriman
>
> We need a "search" endpoint that will allow basic lucene-style searches with
> sorting and pagination options. This endpoint should have a light
> abstraction on top to make it simpler to consume and possibly allow different
> search engines to be used in the future.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
