-
Notifications
You must be signed in to change notification settings - Fork 14
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
Support custom sharding func #239
Conversation
9e82913
to
c8674cf
Compare
c8674cf
to
3b3e08a
Compare
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.
Thanks for changes!
This patchset contains:
- you own changes with implementation of sharding function support
- copy-pasted code from DDL
- my own code for implementation of secondary sharding keys support (because you are moving module
sharding_key.lua
to another directory)
I don't want to spend time on review my own code and code copy-pasted from DDL. Could you split all patchset for at least three commits:
- moving
sharding_key.lua
to a separate dir, commit marked as a part of issue Support custom sharding func #239. Git will show file as a renamed and nothing to review here. - commit with copy-pasted functions from DDL (like
is_called
and other with their tests) - your own changes with sharding function support
if you will do it you will simplify review a lot
2ead6bc
to
78aceb3
Compare
|
It is still valid. |
78aceb3
to
b13e87b
Compare
68b5b5f
to
1e7bf0b
Compare
7c1a1ba
to
8c9f4a0
Compare
4704a94
to
2161b99
Compare
45f9a7d
to
21fe7bf
Compare
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.
While I'm looking on the changes, several minor comments about the 'Separate common sharding metadata methods from sharding key methods' commit.
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.
One comment on 'Add support of custom sharding func for crud 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.
LGTM.
Please, fix several remaining commits. After this it is okay to push from me. Please, review with @ligurio before that.
IMHO, the preliminary commits are good enough now: I'm able to spot what is going on at least. I propose to don't pay more time on polishing them in terms on code layout and so on.
The logic of fetching / caching looks okay too. We'll meet more problems, when will implement automatic reloading, but now it does not require more quirks.
Since this patch presents the implementation of support of DDL sharding function, the number of files associated with sharding will increase in the `common` folder. Therefore, a separate directory was created for files containing methods for working with sharding. Part of #237
…` file PR #181 introduced support of DDL sharding keys. Implementation of sharding keys support contains methods that are common to support sharding keys and sharding functions. That's why a separate file `sharding_metadata.lua` was created to contain common methods. This commit relocates functions for fetching sharding key from `sharding_key.lua` file to `sharding_metadata.lua` file to simplify a reviewer's life and display the history of changes relative to PR #181 in the following commits. Part of #237
It would be more efficient to get sharding keys and sharding functions from storage in one `fetch_on_storage` function call. So, this function is common for sharding keys and sharding functions support. As well as functions for fetching on router. These methods are introduced in `sharding_metadata` module. Methods for working with sharding key structure are introduced in sharding key module. Part of #237
Sharding key cache contains sharding key structures separated by space name. Before this fix if sharding key was incorrect for some space an error was returned and sharding keys that were after the incorrect one did not get into the cache. The solution is to create a variable for an error and write a message to it if an error occurred for the space we are working with, output a warning for other spaces. Part of #237
In DDL PR tarantool/ddl#72 methods for checking and extracting sharding function were introduced. These methods are needed for supporting sharding functions in CRUD as well. In this commit these methods were coppied from DDL and covered by unit tests. Part of #237
21fe7bf
to
37e37c0
Compare
This commit introduces modifications in functions for fetching sharding metadata on storage and router to get sharding function. Function `sharding.key_get_bucket_id` calculates bucket_id using DDL sharding function if sharding function exist for specified space. Description in documentation, integration and unit tests are added as well. Closes #237
37e37c0
to
2887e18
Compare
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
CRUD uses
strcrc32
as sharding function by default.The reason why using of
strcrc32
is undesirable is thatthis sharding function is not consistent for cdata numbers.
In particular, it returns 3 different values for normal Lua
numbers like 123, for unsigned long long cdata
(like 123ULL, or ffi.cast('unsigned long long',
123)), and for signed long long cdata (like 123LL, or
ffi.cast('long long', 123)).
We should leave
strcrc32
function as sharding functiondefault to support existing applications using old version of
CRUD.
There is
_ddl_sharding_func
space as part ofddl
API.This space contains sharding functions specified by user.
So user can specify more reliable sharding function
(like
mpcrc32
) usingddl
API and crud will know aboutthat and will calculate bucket_id by specified sharding func.
Closes #237