Skip to content
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

crud: fix explicit bucket_id in *_many operations #438

Merged

Conversation

DifferentialOrange
Copy link
Member

In case insert_many, insert_object_many, replace_many, replace_object_many, upsert_many or upsert_object_many has been called on a space with custom sharding info and every tuple/object in the request had bucket_id, ShardingHashMismatchError has been returned even though there are no issues with sharding info. For example, some users met this issue while working with tt-ee tt crud import command.

The reason is as follows. To ensure sharding info consistency between the storage and the router, some metainfo is calculated for a request in case bucket_id is generated. In case no bucket_id is generated, no sharding info is passed and consistency check is skipped (since it is not needed). Before this patch, *_many operations haven't skipped consistency check when it was expected due to improper skip_sharding_hash_check flag setup.

Closes #437

I didn't forget about

  • Tests
  • Changelog
  • Documentation (bugfix)

In case `insert_many`, `insert_object_many`, `replace_many`,
`replace_object_many`, `upsert_many` or `upsert_object_many` has been
called on a space with custom sharding info and every tuple/object
in the request had `bucket_id`, `ShardingHashMismatchError` has been
returned even though there are no issues with sharding info. For
example, some users met this issue while working with tt-ee
`tt crud import` command.

The reason is as follows. To ensure sharding info consistency between
the storage and the router, some metainfo is calculated for a request
in case bucket_id is generated. In case no bucket_id is generated, no
sharding info is passed and consistency check is skipped (since it is
not needed). Before this patch, `*_many` operations haven't skipped
consistency check when it was expected due to improper
`skip_sharding_hash_check` flag setup.

Closes #437
@DifferentialOrange DifferentialOrange force-pushed the DifferentialOrange/gh-437-fix-sharding-many branch from cfa496d to 9c1b02e Compare May 17, 2024 11:46
@DifferentialOrange DifferentialOrange changed the title crud: fix explicit bucket_id _many operations crud: fix explicit bucket_id in *_many operations May 17, 2024
@DifferentialOrange DifferentialOrange merged commit e4f0d21 into master May 20, 2024
25 checks passed
@DifferentialOrange DifferentialOrange deleted the DifferentialOrange/gh-437-fix-sharding-many branch May 20, 2024 07:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

_many operations fail to work with bucket specified
2 participants