[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16216287#comment-16216287
]
David Smiley commented on SOLR-11487:
-------------------------------------
Fantastic response to my code review by the way :-)
RE {{aliasMap}}: my suggestion was embarassing; of course the value side should
now be what you have -- just Map!
bq. Based on your earlier response we won't have a collections API call to set
metadata
What's this in reference to? But you've got me thinking... what if this was a
collection-or-alias metadata thing? That sounds pretty useful/cool from a
user/conceptual standpoint. From a code details standpoint... maybe this would
be no change -- alias metadata goes in one place (aliases.json) whereas
collections would theoretically have it in their state.json? Any way I don't
want to create extra work for hypothetical features that are not in scope.
RE ZkStateReader field: Naturally we need to save the data in ZK but that
doesn't require Aliases.java to have the field and it hurts immutability (more
on that in a sec). Couldn't ZkStateReader make this happen (Law of Demeter
perhaps?)?
RE immutability: I believe ZkStateReader is keeping the Aliases instance up to
date via a ZK watcher... so if code doesn't hold a durable reference to Aliases
(outside of ZkStateReader) then we're good? DocCollection is immutable; I
think it's consistent for Aliases to follow the same approach too; no? I don't
think we want to break with the trend here. If it were mutable, the caller
might not be sure when exactly the ZK interaction happens (hidden behind some
innocent method call?). I get this is a trade-off and you've articulated the
other side well I think.
RE Collections.EMPTY_MAP: Okay.
RE Aliases CRUD in ZkStateReader: I like it.
RE TimeOut: nice catch on finding the hot loop! I recommend not copying
TimeOut; just add some utility method if wanted. Classes add more conceptual
complexity than a static method for a case like this IMO.
> 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-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]
