[
https://issues.apache.org/jira/browse/METRON-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16497980#comment-16497980
]
ASF GitHub Bot commented on METRON-1547:
----------------------------------------
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1037
Sidenote, I've also seen this branch fail several times on Travis with some
testing issues around ZK, so even when the existing problems get solved, I'd
like to dig into that more before merging.
An example can be seen at
https://travis-ci.org/justinleet/metron/builds/385698516. I haven't seen
anything in the PR that would directly cause this, but please correct me if I'm
wrong. I'm wondering if we're hitting a tipping point or snag in how we set up
some testing and if this is just the straw that broke the camel's back.
> Solr Comment Fields
> -------------------
>
> Key: METRON-1547
> URL: https://issues.apache.org/jira/browse/METRON-1547
> Project: Metron
> Issue Type: Sub-task
> Reporter: Justin Leet
> Assignee: Justin Leet
> Priority: Major
>
> Right now the Solr schemas don't have comment fields defined. It'll get
> caught by the catch all with ignored type not multivalued.
> ES just handles this correctly out of the box, but we'll need to take care of
> it in Solr and document the schema restriction.
> This actually is probably fairly problematic in comparison to ES. Solr
> doesn't support an easy way of doing a complex structure without doing
> something a bit weird (like parsing a string representation) or miserable
> (nested document).
> This will be incompatible with the current comment update system (just using
> the patch() functionality). Preferably we need to add a new REST endpoint for
> comments specifically so that we can handle it without the frontend knowing
> the backend system. This also involves adjusting the UI to use the new REST
> API, along with testing for both ES and Solr.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
