[jira] [Commented] (SOLR-11487) Collection Alias metadata for time partitioned collections

["David Smiley (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org