[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395215#comment-16395215 ] David Smiley commented on SOLR-11617: - Looks good except for a minor omission I can fix now. CHANGES.txt ought to be updated, and the collections-api.adoc have a couple examples of v1 that you changed to "properties.*" that should have been "property.*" (it's V1 not V2). I'm running precommit and tests. It should be committed relatively soon. Thanks for doing the renames Gus! > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16394833#comment-16394833 ] Gus Heck commented on SOLR-11617: - Added another commit addressing comments > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16394358#comment-16394358 ] David Smiley commented on SOLR-11617: - BTW Gus added a new PR for the renames (it's auto-linked thanks to JIRA-GitHub integration). Next time please comment here so Watchers get notified. > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[
https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392083#comment-16392083
]
Gus Heck commented on SOLR-11617:
-
It does say so in the description, but if you don't read the _introspect
carefully you'll quite easily get confused I think.
{code:java}
"properties": {
"type": "object",
"documentation":
"https://lucene.apache.org/solr/guide/defining-core-properties.html";,
"description": "Allows adding core.properties for the collection. Some
examples of core properties you may want to modify include the config set, the
node name, the data directory, among others.",
"additionalProperties": true
},{code}
> 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
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR_11617.patch, SOLR_11617.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392067#comment-16392067 ] David Smiley commented on SOLR-11617: - bq. which I believe translate to "core" properties Yeah I was gonna mention that it's pretty confusing that Solr's create collection API doesn't make that important clarification about what sort of properties these are. It really ought to! > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[
https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392059#comment-16392059
]
David Smiley commented on SOLR-11617:
-
Further unifications sounds good, again for 8.x. For now lets try to have
consistent names in the API.
* (v1) "MODIFYALIAS" -> "ALIASPROP".
* (v2) "modify-alias" -> "set-alias-property". "metadata" -> "properties" json
object. Note that the collection property mechanism is defined on
{{collections.collection.Commands.json}} whereas modify-alias is defined on
{{collections.Commands.json}} -- pretty confusing.
* (SolrJ) CollectionAdminRequest.modifyAlias -> setAliasProperty. Harmonize
methods a bit more to that of setCollectionProperty.
* rename "metadata.\*" prefix parameters to "property.\*" v1 and in v2
"properties" parent object
* edit pertinent documentation to refer to "property" or "properties" instead
of "metadata". A parenthetical mention that properties are metadata is
helpful, but we shall call them properties.
That's about as much as we can handle right now.
The paint is still wet on SOLR-11960, so to speak. Before it's API gets set in
stone (by a 7.3 release), perhaps now is the last moment to give the API more
of a bulk parameter feel (like here for aliases) instead of limited to one at a
time? Even if the code can only handle one pair right now, at least the API
would be what we want it to be.
BTW the solr config API itself has "properties" too :-) "set-property" and
"unset-property" v2.
[~romseygeek] (7.3 RM) it's pretty important we do a little something here for
7.3. Bare minimum is we put "experimental" warnings both here (for alias
metadata/properties) and SOLR-11960 (collection properties), or perhaps we can
do a bit better for our users sake.
> 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
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR_11617.patch, SOLR_11617.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[
https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391961#comment-16391961
]
Gus Heck commented on SOLR-11617:
-
Another thing to think about is that this exists
{code:java}
POST /api/c
{ "create": {
"name": "foo",
// etc etc...
"properties":{
// arbitrary properties here
}
}
}{code}
which I believe translate to "core" properties... I'm suddenly realizing that
the distinction between that and collection properties in SOLR-11960 is
confusing, especially with this notation in the v2 api.
> 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
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR_11617.patch, SOLR_11617.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[
https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391884#comment-16391884
]
Tomás Fernández Löbbe commented on SOLR-11617:
--
True. In the V2 API you can set cluster properties with a "set-property" on
/cluster. Maybe we should rename the collection properties form
{{set-collection-property}} to {{set-property}} too (in the
/collections/\{collection} path). Unfortunately replica properties are also set
in the same target. Not sure if there is a
/collections/\{collection/replicas/{replica} path to use. Also, then there
would be a set-property /cluster/aliases/\{alias}?
> 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
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR_11617.patch, SOLR_11617.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391868#comment-16391868 ] Gus Heck commented on SOLR-11617: - Naming consistency is good, but we still have N api's that do something similar just with slightly different targets. I think further unification is possible by allowing arbitrary targets with a consistent naming convention for targets (8.x type thing though, definitely not this issue) > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[
https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391564#comment-16391564
]
Tomás Fernández Löbbe commented on SOLR-11617:
--
I think that's a great idea. We should try to unify the API regardless of the
implementation. We now have {{CLUSTERPROP}}, {{COLLECTIONPROP}}, we could make
this API be {{ALIASPROP}}, and maybe we could also modify the API of "replica
properties", from {{ADD/DELETEREPLICAPROP}} to {{REPLICAPROP}}, and work in the
same way others work ( {{null}} value unsets the property).
Also:
{quote}It seems this API can only handle setting one name-value at a time.I
think it should be a bunch
{quote}
+1 (looks like this is already supported for alias metadata). We should add
something similar to the other "PROPS" if they don't have that already.
{quote}When creating an alias, we can specify the metadata with a prefix, e.g.
"metadata.route.field" would set the "route.field" metadata
{quote}
+1, we should have that for COLLECTIONPROP. We already have that for Replica
props I think
> 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
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR_11617.patch, SOLR_11617.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391492#comment-16391492 ] David Smiley commented on SOLR-11617: - Now that there is a "collection property" API [~tomasflobbe], I was thinking we should quickly mark the "alias metadata api" as experimental for 7.3 so that we are more free to change it, to harmonize it with the "collection property" one. Perhaps we need only harmonize the names a bit "alias properties", not "alias metadata", keeping everything the same. Or maybe go further. I very much welcome your input. > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16353346#comment-16353346 ] ASF subversion and git services commented on SOLR-11617: Commit 3251679abd3f4cb8325423ab0d96ff71bcb198e2 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3251679 ] SOLR-11722 SOLR-11617: Alias tests: Ensure zkStateReader's view is up to date before acting (cherry picked from commit 812d400) > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16353344#comment-16353344 ] ASF subversion and git services commented on SOLR-11617: Commit 812d400807bcebc782f85dcf3bba5619421880cb in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=812d400 ] SOLR-11722 SOLR-11617: Alias tests: Ensure zkStateReader's view is up to date before acting > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342866#comment-16342866 ] ASF subversion and git services commented on SOLR-11617: Commit 16e80e6a33e3e6029437c804a3a6b5944a51aafa in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=16e80e6 ] SOLR-11617: Fix test: delete aliases without async in tearDown (cherry picked from commit 00d453d) > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342859#comment-16342859 ] ASF subversion and git services commented on SOLR-11617: Commit 00d453d27c36b9c52928b5ccd1946a2e2aee5c75 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=00d453d ] SOLR-11617: Fix test: delete aliases without async in tearDown > 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 >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342745#comment-16342745 ] ASF subversion and git services commented on SOLR-11617: Commit e3fc0631960cdd9b6bf05a939045480f0ab4b18e in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e3fc063 ] SOLR-11617: Alias metadata API; returned from LISTALIASES, set via MODIFYALIAS (cherry picked from commit 154bdeb) > 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 > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342744#comment-16342744 ] ASF subversion and git services commented on SOLR-11617: Commit 154bdeb7db1794c4019ceb1c27b47ff6159a08e8 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=154bdeb ] SOLR-11617: Alias metadata API; returned from LISTALIASES, set via MODIFYALIAS > 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 > > Time Spent: 20m > Remaining Estimate: 0h > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342496#comment-16342496 ] Gus Heck commented on SOLR-11617: - Pull request updated, thought that was supposed to result in a message here, but it doesn't seem to. I removed the parameter for whitespace optionality but also removed the requirement. As I said above I'm not able to convince myself that there isn't a use case for a value that is whitespace so If there isn't going to be an option, then we probably should allow it. Tests & a CollectionAdminRequest method/class were added. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336864#comment-16336864 ] ASF GitHub Bot commented on SOLR-11617: --- GitHub user fsparv opened a pull request: https://github.com/apache/lucene-solr/pull/310 SOLR-11617 Changes as mentioned in Jira comment, plus rather than decide I provided an option for the user to enable whitespace values. By default this is off and whitespace values are treated as null, but if the user really wants to set a value to 3 spaces they can by passing allowWhitespaceValues=true. I'm fairly set against pure whitespace keys unless someone can supply up with a good reason for that. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nsoft/lucene-solr SOLR-11617 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/310.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #310 commit 959401b9ac6bac5e4d696a750c3e5eb42b7da9f5 Author: gus Date: 2018-01-23T19:28:11Z SOLR 11617 - patch 2 commit 218890d7b8c01bddabd1de2a6bbe2f1735ac238c Author: Gus Heck Date: 2018-01-23T20:43:54Z Merge branch 'master' into SOLR-11617 commit 4b4c656a107eba82ec1bfe11e8f5b14b1ea751bf Author: Gus Heck Date: 2018-01-24T03:44:46Z adjust for package changes in master > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329672#comment-16329672 ] Gus Heck commented on SOLR-11617: - * I don't really want to create two ways to modify aliases (and 2 places to maintain the functionality) I'll leave MODIFYALIAS as is unless additional opinions surface. * I don't think we accept whitespace for collection names etc and I think that it's not very friendly to make whitespace significant in general. I'm generally thinking that metadata keys should be trimmed. It would be a very strange use case to want to be able to set values for keys like ' foo', 'foo ' and ' foo '.. and much more common for such a thing to result in confusing debugging sessions. for values, it feel a bit trappy to set a value of ' ' instead of deleting if the person issuing the command accidentally appends a space... However, I suppose there's some possibility that someone might want to keep a metadata property that contained a delimiter and have that delimiter be whitespace... for values its a trade off i guess. I could go either way. * multi-properties, yeah that would be good. * Linked Hash Map (/) > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16278853#comment-16278853 ] David Smiley commented on SOLR-11617: - Nice work Gus. I can see your point about the name of MODIFYALIAS name being a bit dubious but I suppose it's a matter of perspective. If you view the alias & metadata as entirely separate then I think your recommendation for a different name is right. I think the user can think of this like collection configuration, which is basically metadata in a sense. I still like the name MODIFYALIAS. Maybe MODIFYALIAS should allow specifying what it points to as well as being usable for metadata? Granted I don't love having two ways to do one thing that are arbitrary but it at least enhances the sensibility of the MODIFYALIAS name/purpose. Why the "or whitespace" qualification in the implementation and thus docs around the metadata value? Do other V2 API commands work this way? If so then keep it but otherwise I think whitespace shouldn't be special. It seems this API can only handle setting one name-value at a time. I think it should be a bunch, perhaps using the sub-properties mechanism in the v2 doc, which _I think_ translates to say meta.mykey1=myvalue1&meta.mykey2=myvalue2 assuming we have a "meta" prefix. minor: When returning the metadata, I think the outgoing map should be a LinkedHashMap so that the alias names are in the same order as earlier (whatever that may be). > 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 > 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 (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266406#comment-16266406 ] Gus Heck commented on SOLR-11617: - After looking at the ref guide documentation, and trying to write some for MODIFYALIAS, it occurs to me that the MODIFYALIAS name is somewhat confusing... As documented in the ref guide one can "modify" an alias by changing what it points to by issuing a second create command that just overwrites the previous collection list for the alias. However "MODIFYALIAS" won't provide any functionality actually modifying the alias itself... and only relates to metadata? Maybe ALIASMETADATA would be a better, less confusing name? > 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 > Attachments: 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 (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266284#comment-16266284 ] Gus Heck commented on SOLR-11617: - Also docs yet to created for this... > 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 > Attachments: 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 (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Metadata CRUD in REST API
[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
