[
https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16338646#comment-16338646
]
ASF GitHub Bot commented on SOLR-11617:
---------------------------------------
Github user dsmiley commented on the issue:
https://github.com/apache/lucene-solr/pull/310
Nice docs. Lets not provide an option to configure whitespace/trim
handling -- configuration-itis. IMO we should be consistent with other parts
of Solr on what to do (e.g. props on core creation) but you seem to feel
strongly about it so whatever. It's not that I don't disagree with your point
of view, it's only that I think consistency is a higher virtue.
Can you add a test please? It could be a simple modification to an
existing test.
> Expose Alias Metadata CRUD in REST API
> --------------------------------------
>
> Key: SOLR-11617
> URL: https://issues.apache.org/jira/browse/SOLR-11617
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: master (8.0)
> Reporter: Gus Heck
> Priority: Major
> Attachments: SOLR_11617.patch, SOLR_11617.patch
>
>
> SOLR-11487 is adding Java API for metadata on aliases, this task is to expose
> that functionality to end-users via a REST API.
> Some proposed commands, for initial discussion:
> - *SETALIASMETA* - upsert, or delete if blank/null/white-space provided.
> - *GETALIASMETA* - read existing alias metadata
> Given that the parent ticket to this task is going to rely on the alias
> metadata, and I suspect a user would potentially completely break their time
> partitioned data configuration by editing system metadata directly, we should
> either document these commands as "use at your own risk, great
> power/responsibility etc" or consider protecting some subset of metadata.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
