-
Notifications
You must be signed in to change notification settings - Fork 986
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
ZUNION/ZINTER commands introduced #1469
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1469 +/- ##
============================================
- Coverage 78.77% 78.77% -0.01%
- Complexity 6225 6242 +17
============================================
Files 462 463 +1
Lines 20790 20847 +57
Branches 2300 2300
============================================
+ Hits 16378 16422 +44
- Misses 3347 3362 +15
+ Partials 1065 1063 -2
Continue to review full report at Codecov.
|
Thanks a lot, will have a look on Monday. |
Care to rebase your PR. Merging #1456 introduced some conflicts. |
9999703
to
492c8ae
Compare
Done |
0ef07d4
to
ac87d7a
Compare
* @param keys the keys. | ||
* @return List<V> array-reply list of elements. | ||
*/ | ||
List<V> zunion(long numkey, ZStoreArgs storeArgs, K... keys); |
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.
My only concern on this - naming issue. We reuse similar ZStoreArgs but these commands even do not have "store" in their names. Shall we introduce just a wrapper class with new name which only extends it?
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.
Reuse ZStoreArgs
is fine to me. : ) . @mp911de Can you share you opinions for this?
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.
ZStoreArgs
doesn't really fit the new commands. While it was fine when we only had Z…STORE
commands, the new variants require something better.
I'd suggest introducing ZAggregateArgs
and retrofitting ZStoreArgs
so that ZStoreArgs extends ZAggregateArgs
. We don't need to deprecate anything. Related, introducing zunionstore(…, ZAggregateArgs, …)
doesn't provide more value over zunionstore(…, ZStoreArgs, …)
, therefore we should keep the existing methods as-is.
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.
@mp911de I do personally like the approach with introducing ZAggregateArgs
where ZStoreArgs extends ZAggregateArgs
.
But, unfortunately, we still have to ship to ZStoreArgs
all builder methods (since they are statically dispatched) and override all setter methods to return ZStoreArgs
. With current PR code, this code would not compile:
ZStoreArgs args = ZStoreArgs.Builder.max()
So I'm a bit confused of how to do it with neither API breaking changes nor tons of boilerplate.
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.
👍 . Can you add also @since
tags (version 6.1) to all newly introduced public methods?
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.
The PR is a great starting point.
There are two general issues to address:
-
Public API methods (and their implementations) should be sorted alphabetically. We have a ton of methods already and alphabetical ordering makes it simple to find the methods in the code.
-
I'd suggest introducing
ZAggregateArgs
instead of reusingZStoreArgs
. See the comment below.
Let me know if there's anything unclear or to discuss.
src/main/java/io/lettuce/core/api/async/RedisSortedSetAsyncCommands.java
Show resolved
Hide resolved
* @param keys the keys. | ||
* @return List<V> array-reply list of elements. | ||
*/ | ||
List<V> zunion(long numkey, ZStoreArgs storeArgs, K... keys); |
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.
ZStoreArgs
doesn't really fit the new commands. While it was fine when we only had Z…STORE
commands, the new variants require something better.
I'd suggest introducing ZAggregateArgs
and retrofitting ZStoreArgs
so that ZStoreArgs extends ZAggregateArgs
. We don't need to deprecate anything. Related, introducing zunionstore(…, ZAggregateArgs, …)
doesn't provide more value over zunionstore(…, ZStoreArgs, …)
, therefore we should keep the existing methods as-is.
a191fa5
to
3dfc469
Compare
3dfc469
to
7556ae1
Compare
7556ae1
to
905d985
Compare
Yep, my bad. Added. |
Going to take this PR from here. |
Revert zinterstore/zunionstore accepting ZAggregateArgs to retain binary compatibility. Remove numkey parameter as this parameter can be calculated from the number of specified keys to simplify API usage. Reinstate builder and override methods in ZStoreArgs to retain binary compatibility. Tweak Javadoc, add author tags and license headers. Fix Coroutines zmscore signature. Original pull request: #1469.
Thank you for your contribution. That's merged and polished now. I especially reverted the changes for |
#1450