[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16250254#comment-16250254
]
David Smiley commented on SOLR-11487:
-------------------------------------
Looks like we're finally super close!
Aliases:
* good -- all my feedback below is little stuff
* you can use aliasMap.computeIfAbset to reduce the LOC
* maybe use "getZNodeVersion" naming to be consistent with DocCollection
* resolveAliases: it has a null check here but I think it's not necessary;
resolveAliasesGivenAliasMap handles this.
* getCollectionAliasListMap seems to replace it's content with unmodifiable
Lists each time it's called which I think is bad. I suggest not wrapping the
List<String> collection values in this method; instead we can do that on
creation? The outer unmodifiableMap call here is fine, however... again if
we're going to do the unmodifiable list wrapping on creation, might as well do
so for the map too? BTW I'm fine with removing some or all of this immutable
wrapping because this is internal code. I tend to do this wrapping too but if
it's painful (and it's painful here!) I'm not religious about it.
* I got what you were saying earlier in this issue about EMPTY_MAP but
(thankfully) we're no longer doing instanceof equality with EMPTY_MAP so we can
just not use EMPTY_MAP (directly) anymore; right?
* cloneCollectionMetadataMap: the outer recreation of the HashMap is pointless
because you're ultimately overwriting the reference and replacing it. You
could keep the check for null but in that event, exit early with a new empty
HashMap.
ZkStateReader:
* in IRC we spoke about removing the modification equality check in the loop of
applyModificationAndExportToZk; did you change your mind? I think it's fine
either way FWIW.
bq. see comment/code in ZkStateReader around L1495.
Yeah, if we can't save in a few tries (ZK BadVersionException each time), it's
hard to believe trying again will be successful. Either timeout or fix #
retries; I don't care. Why did you add the sleep?
> 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_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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
