gus-asf commented on code in PR #864:
URL: https://github.com/apache/solr/pull/864#discussion_r874314223
##########
solr/core/src/java/org/apache/solr/cloud/api/collections/CreateAliasCmd.java:
##########
@@ -140,15 +145,21 @@ private void callCreateRoutedAlias(
Sets.difference(routedAlias.getRequiredParams(),
props.keySet()), ','));
}
- // Create the first collection.
- String initialColl = routedAlias.computeInitialCollectionName();
- ensureAliasCollection(
- aliasName, zkStateReader, state, routedAlias.getAliasMetadata(),
initialColl);
+ Aliases aliases = zkStateReader.aliasesManager.getAliases();
+
+ List<String> collectionList = aliases.resolveAliases(aliasName);
+ String collectionListStr = String.join(",", collectionList);
Review Comment:
Yeah at one point I thought it read better this way, but not so sure in
retrospect. I think you'd have to work hard to create an alias structure that
was noticeably expensive here (i.e one that was non-routed and contained many
aliases that each pointed to many other aliases so that we had a large number
of iterations in the downstream methods and even if you did it might get
optimized by the compiler/JIT anyway... And anything over 1k collections is
likely facing much more important performance issues... Certainly the normal
cases are one collection and some small number of collections under an alias.
Not to mention it's hard to think of a real use case where CREATEALIAS really
is issued frequently enough to impact performance, but I think I'll change it
anyway because I really am not sure my way is easier to read after all, and
after all the implementation of the resolve could change one day to do
something more expensive like support arbitrary depth recursively rather than
jus
t 2 levels and who knows, we may get good at handling millions of collections
someday...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
