[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245905#comment-16245905
]
Gus Heck commented on SOLR-11487:
---------------------------------
* Consolidation of the alias related stuff in ZkStateReader is nice.
* I think the getter would be consistent and play nicer with IDE auto complete,
but as you say, its more of a taste/style issue, not a material issue.
* The use of UnaryOperator rather than Function<Aliases,Aliases> of course
makes good sense
* I suspect in this patch the int version should also be volatile, but I
haven't looked carefully enough to see if we have sufficient monitor locking to
make that unnecessary yet...
* I don't like moving the version out of the Aliases object. The version in zk
that this instance was derived from is information about the Aliases object and
therefore should be a property of the object. I like it much better as an
immutable property on Aliases that is set directly upon creation, and can be
made accessible from the Aliases object (don't recall if I provided a getter in
my patch but it should probably be there to support folks who are working with
aliases and some other data in zk so they can know if changes to aliases.json
have occurred). Future modifications to the code could more easily get the
version out of sync this way by failing to update the field in AliasManager
whereas having it as required in the constructor enforces and communicates the
need to track the version.
* This patch places the burden of coordinating a set of changes on the caller
of the API instead of handling it transparently. This is reflected by line 111
in Test where you wrapped the previously independent clone operations in a
single UnaryOperator, which basically redesigns the test such that it passes
due to the special case in the test of consecutive invocations that are easily
wrapped together. The present patch will require that UnaryOperation be used
like a transaction wrapper whereas the previous patch tracked changes
internally and then transparently re-applied them in the event of a conflict.
This made series of changes transactional by default without any explicit
coordination code on the caller's part, and thus somewhat fool proofed the
usage of the API. If substantial logic is involved in calculating multiple
pieces of metadata and/or a collection name and that logic that has to all be
applied at the same time to ensure consistent information in zookeeper then ALL
that logic has to be place inside the UnaryOperation. In the Prior patch it was
sufficient to perform several clone operations and then exportToZk with no
effect on the organization of the calling code. I feel this patch simplifies
the current code by adding complexity to future code using the API.
* AliasIntegrationTest.test() seems to fail?
> 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-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]
