-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SOLR-16393 Cosmetic, REST-fulness improvements to v2 alias, alias-prop #1332
Conversation
@gerlowskija if you have some time, please take a look! |
Hey, thanks for the PR Alex. A lot of these have been blocked for awhile on SOLR-16531, but that's close enough to closed out that we should be good to start transitioning APIs again. I'll take a look shortly! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
list-aliases API looks great @stillalex. Left a comment or two but nothing of import.
You're planning to add a few other APIs to this PR it sounded like, or do you want to handle those in separate PRs? (Either approach works for me 🤷 )
* </code> API. | ||
*/ | ||
@Path("/aliases") | ||
public class GetAliasesAPI extends AdminAPIBase { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[0] Nitpick that you can def ignore, but I'd prefer the name ListAliasesAPI
for this class instead. Right now Solr has no API to fetch information about a single alias, but it'd be a reasonable API to add at some point. And if that ever happens, it'd be hard for a reader to distinguish between GetAliasesAPI and GetAliasAPI without a double-take 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, renaming makes sense
solr/core/src/java/org/apache/solr/jersey/SolrRequestAuthorizer.java
Outdated
Show resolved
Hide resolved
thanks for talking a look. I think I wanted to have a more complete PR with all apis. will try to add more to this, but if it turns into too much code, I will opt for splitting, it will also make the review a bit easier I guess. |
b23f43e
to
1a85af1
Compare
1a85af1
to
23b94bd
Compare
Small heads up for you @stillalex - I know it's tempting to force-push, but we've found that it can do weird things to Github comment history and make PRs just that bit harder to review. Obviously sometimes things get messy and you have to do what you have to do, but try to avoid those where you can at least please! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Alex - everything here looks great, but there's one tiny piece missing:
There's actually a v2 API in the class ClusterAPI
that implements the list-alias functionality. We should delete that and remove its registration from CollectionsHandler.
It should only take a minute or two so I'll take a crack at that, and run the tests again. Other than that though, this all looks good to go!
Alright, I fixed the ClusterAPI duplicate I mentioned, but in the process I found a few other things that were worth discussing here. Specifically, the response that comes back from
AFAICT |
ouch, good catch! you are absolutely right, I missed this completely. for sure the collections list needs to be present. any preference on the format? what about 'collections' (similar to the name used when creating the alias)?
|
@gerlowskija added the new entry in the response, a test for the new api and updated the guide. please take a look! |
@gerlowskija gentle ping. please take another look and let me know your thoughts |
Hey, sorry for the delay in circling back to this @stillalex - will take a look shortly with a mind to commit. Careful about doing this. If I'd happened to push up some tweaks or something around the same time, they could've been blown away. It also does weird things with line-level review comments in the Github UI, that can be a bit of a pain when reviewing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; only one minor comment that I can cleanup prior to merge.
|
||
final CoreContainer coreContainer = fetchAndValidateZooKeeperAwareCoreContainer(); | ||
ZkStateReader zkStateReader = coreContainer.getZkController().getZkStateReader(); | ||
// if someone calls listAliases, lets ensure we return an up to date response |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[-0] Small nit: copy/paste issue with 'listAliases'.
Relatedly though, maybe this code should be pulled into a private helper method that both getAliasByName
and getAliases
can call, to cut down on duplication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
thank you @gerlowskija for the help in getting this merged! |
https://issues.apache.org/jira/browse/SOLR-16393
Description
List Aliases apis only.
Solution
List Aliases api responses:
Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Checklist
Please review the following and check all that apply:
main
branch../gradlew check
.