[
https://issues.apache.org/jira/browse/SOLR-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16307276#comment-16307276
]
Gus Heck commented on SOLR-11722:
---------------------------------
*Routing Field:* I'm quite happy if we don't need to check the routing field
for existence. That would be very difficult, I just felt it slightly weird that
I was able to validate all the other inputs and not that.
*GregorianCalendar:* I'll certainly move to the new API, old habits... thx.
*parseCollectionCreationProps:* I'll look at your way with LocalSolrRequest. I
was never fond of having to touch the create command, but I really really
didn't want to duplicate it....
*duplication in collections.Commands.json:* I definitely also hate this, but I
think the v2 api is going to reject anything it doesn't recognize and also if
there's nothing there, then there's no "self documenting" for v2 for all the
collection creation bits. Even worse, there are some differences in what we
accept vs the create command. Most notably we can't accept a name for the
collection (although we possibly could turn that into a prefix, we would need
to document that, meaning). Also async and waitForState need to be trimmed off
as they don't make sense as part of a sub-command. Also the description needs
to differ...
I don't think the v2 API design anticipated command reuse that was user
configurable. If we worked from an example collection, this issue would go
away, but your points on that front with respect to extra steps and replica
allocation remain valid. If we could rename the example collection, that second
issue would get a lot better, but alas there is no collection renaming aside
from aliases AFAICT, and I don't think we want to go there...
So solve this duplication and keep things pretty and normalize in the JSON, it
would need to move to JSOG or some other strategy for cross linking in JSON,
and furthermore facilitate masking/overlay to edit out and replace the parts
that need to differ in the create-routed-alias context. That's obviously a
huge, unreasonable change to include within this ticket.
However as I write this, I recall noticing during my testing of this that
properties is of type object, and has no sub-documentation. I suspect we could
just omit things in the same fashion. So maybe V2 is more tolerant than I
thought. Initially it obviously complained about not having a collection-create
element... It looks like if we set additional properties to true, we could
leave properties blank, Not sure if that's going to work at that level, or with
the nested stuff though. If it does work, we could omit this *at the expense of
not completely documenting what we provide in _introspect*...
*V2 to V1:* The v2 to v1 translation stuff was trapped in a private method
where it modified the request object by wrapping the params in an anonymous
subclass of SolrParams that returns V1 params instead of V2 params. This didn't
suit us because our request object is for the create-routed-alias command and
we don't want it modified. It might be that moving to a LocalSolrRequest as you
suggest avoids the need to extract this.
That said I wonder about this code in general... there's lots of usages of
setParams out there, someone down stream of one of those may be expecting a
particular subclass of SolrParams....
*"collection-create":* yeah, not the greatest name. Threw it in there to stop
my minutes of name pondering and get on with things. Maybe "create-with" ? or
"create-options" or "create-params"? ... "cparams" or "copts" is nice and
concise, but cryptic.
Hoping others have an opinion here, naming stuff is hard :)
> API to create a Time Routed Alias and first collection
> ------------------------------------------------------
>
> Key: SOLR-11722
> URL: https://issues.apache.org/jira/browse/SOLR-11722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Attachments: SOLR-11722.patch
>
>
> This issue is about creating a single API command to create a "Time Routed
> Alias" along with its first collection. Need to decide what endpoint URL it
> is and parameters.
> Perhaps in v2 it'd be {{/api/collections?command=create-routed-alias}} or
> alternatively piggy-back off of command=create-alias but we add more options,
> perhaps with a prefix like "router"?
> Inputs:
> * alias name
> * misc collection creation metadata (e.g. config, numShards, ...) perhaps in
> this context with a prefix like "collection."
> * metadata for TimeRoutedAliasUpdateProcessor, currently: router.field
> * date specifier for first collection; can include "date math".
> We'll certainly add more options as future features unfold.
> I believe the collection needs to be created first (referring to the alias
> name via a core property), and then the alias pointing to it which demands
> collections exist first. When figuring the collection name, you'll need to
> reference the format in TimeRoutedAliasUpdateProcessor.
--
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
