[
https://issues.apache.org/jira/browse/METRON-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16083633#comment-16083633
]
ASF GitHub Bot commented on METRON-1022:
----------------------------------------
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/636
Looking at this implementation and working a bit on the PoC for index data
mutation, I think the abstraction here isn't in the right place. It's too
bound-up in the REST layer whereas data access has traditionally existed
further down in the abstraction layer. It's a smell that metron-rest has to
depend on ES at all. That dependency should be provided at runtime entirely.
Also, we're going to need data access in batch as well and I'd like a sensible
abstraction in place to enable that (e.g. merging modified records when reading
as part of a Spark or MR job).
It seems to me that we need a DAO abstraction living in `metron-writer` or
even `metron-indexing` for interacting with indices with the concrete
implementations existing in `metron-elasticsearch` and `metron-solr` for ES and
Solr respectively. I think `metron-rest` should work entirely on abstract
classes. The REST layer should choose the DAO implementation via reflection
and we should adjust the classpath in the shell script to include one of
`metron-elasticsearch` or `metron-solr`. In essence, I'm recommending
something similar to how JDBC works where you choose your driver implementation
via reflection (often) and work with base JDBC classes from there.
> 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)
