[ 
https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245727#comment-16245727
 ] 

David Smiley commented on SOLR-11617:
-------------------------------------

Perhaps we don't need entirely separate commands.  When we retrieve aliases 
today to list them, we can return the metadata in a new separate section (easy 
back-compat).  When creating an alias, we can specify the metadata with a 
prefix, e.g. "metadata.route.field" would set the "route.field" metadata.  This 
is consistent with such settings on collection creation.  

One new command "MODIFYALIAS" could be used to set alias metadata on an 
existing alias.  This "MODIFY" prefix is consistent with "MODIFYCOLLECTION" in 
naming convention.  In the future, perhaps we might abuse MODIFYALIAS slightly 
to not just be about setting metadata, but to effectively issue commands to 
time partitioning, like to tell it to create a new collection, rolling new 
indexing traffic to it.

BTW during implementation keep in mind the V2 stuff, including introspect.

> 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
>
> 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
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to