[
https://issues.apache.org/jira/browse/METRON-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16498418#comment-16498418
]
ASF GitHub Bot commented on METRON-1547:
----------------------------------------
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1037
@cestella For that indexString thing, we could do a couple things
- Leave it as-is for now, and fix both when they need to be.
- Figure out how to fix it and fix both here.
- Drop index from this query entirely. Given that we have source type, it
should be sufficient.
I personally lean towards the last one, unless we either know a fix is
imminent or it's easy to do. Index is pretty extraneous given that we use
source type everywhere and we can do a lookup on the source type anyway.
Any preference?
> 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)
