[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240417#comment-16240417
]
David Smiley commented on SOLR-11487:
-------------------------------------
Aliases
* constructor is confusing to me; you save aliasMap to a field and *then* swap
with EMPTY_MAP if you can? Why not before? And maybe we can simply not bother
with initializing the metadata map here... worry about that when we
get/populate it. It'll probably simplify seeing that the get/set code for it in
other methods will be correct since won't require assumptions about being
initialized.
* in general... these changes invoke "convertMapOfCommaDelimitedToMapOfList"
way more than before. It used to be only at Alias construction, now it's at
every call to resolveAliases (!) and getCollectionAliasListMap. Sorry but can
we avoid that? I think it's not a big deal to lazy split the value for the
particular collection being requested, but doing so for all collections seems
excessive to me.
* convertMapOfCommaDelimitedToMapOfList: you've converted this to Java 8
streams which is fine. However you've wrapped the result in new LinkedHashMap
which actually doesn't retain the original order of the input since
Collectors.toMap is going to use a HashMap inbetween. toMap is overloaded with
a Supplier<Map>; you can call that one suppling the LinkedHashMap.
* The introduced use of a field priorChange Function seems really hokey; I
sorta see what you're doing with it but I think we need to go about this in
some other way. It feels like too much of a wart on Aliases. Maybe we can chat
about this on IRC.
*From a Solr API perspective, it seems we've forgotten to expose the read/write
of metadata; no? (!)* I feel badly I didn't recognize this earlier; it's
obvious in retrospect. When in Solr tests we can work directly with ZooKeeper
and Solr's internals, it's easy to forget the need for a public API.
ZkStateReader
* exportAliasToZk computes a new Aliases instance at the first line
(Aliases.cloneWithCollectionAlias) before calling exportAllAlias then
checkForAlias, both of which have loops to do their jobs with retries /
re-checking. It's hard for me to see how this is correct... shouldn't
Aliases.cloneWithCollectionAlias be called _within_ a loop?
* nice use of aliasLock with wait & notifyAll
* minor: aliasWatcher & aliasLock fields should probably be adjacent to aliases.
> Collection Alias metadata for time partitioned collections
> ----------------------------------------------------------
>
> Key: SOLR-11487
> URL: https://issues.apache.org/jira/browse/SOLR-11487
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Attachments: SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch
>
>
> SOLR-11299 outlines an approach to using a collection Alias to refer to a
> series of collections of a time series. We'll need to store some metadata
> about these time series collections, such as which field of the document
> contains the timestamp to route on.
> The current {{/aliases.json}} is a Map with a key {{collection}} which is in
> turn a Map of alias name strings to a comma delimited list of the collections.
> _If we change the comma delimited list to be another Map to hold the existing
> list and more stuff, older CloudSolrClient (configured to talk to ZooKeeper)
> will break_. Although if it's configured with an HTTP Solr URL then it would
> not break. There's also some read/write hassle to worry about -- we may need
> to continue to read an aliases.json in the older format.
> Alternatively, we could add a new map entry to aliases.json, say,
> {{collection_metadata}} keyed by alias name?
> Perhaps another very different approach is to attach metadata to the
> configset in use?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
