scan: fix nil filters #425
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DifferentialOrange
force-pushed
the
DifferentialOrange/gh-422-nil-conditions
branch
2 times, most recently
from
ee1de7a to
ffa15ea
Compare
There seem to be no reason to determine features on request instead of require since this operation is cheap. Part of #422
DifferentialOrange
force-pushed
the
DifferentialOrange/gh-422-nil-conditions
branch
3 times, most recently
from
a5f10cd to
4de7d35
Compare
Generate `tarantool_supports_X` utils instead of creating a manual function for each key with copypaste. Part of #422
`pcall(require, module)` check is insufficient for external types since module presence often precedes box format support and index support for a type. Sometimes the nature of the module may change between versions: for example, there is a `'uuid'` module in 1.10.x, but a separate type was introduced only in 2.4.1 Part of #422
Test scenarios which imitate "server fail" leave test cluster malfunctioning even in cartridge case. Part of #422
Before this patch, some nil conditions failed with internal filter library build error. This patch fixes this internal error, as well as normalize filters to behave similar to core indexes. The logic in core Tarantool select is as follows. `nil` condition in index select is an absence of condition, thus all data is returned disregarding the condition (condition may affect the order). `box.NULL` condition is a condition for the null value -- in case of EQ, only records with null index value are returned, in case of GT, all non-null values are returned since nulls are in the beginning of an index and so on. `nil`s and `box.NULL`s in tuple are both satisfy `box.NULL` equity. After this patch, `nil` filter condition is treated as no condition. This is a breaking change since conditions for `'>'` and `'<'` operator with `nil` operand had resulted with empty response before this patch. But since it was inconsistent with scanning index conditions and wasn't intentional, we change it here. Closes #422
DifferentialOrange
force-pushed
the
DifferentialOrange/gh-422-nil-conditions
branch
from
4de7d35 to
17dd0bb
Compare
better0fdead
approved these changes
Mar 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before this patch, some nil conditions failed with internal filter library build error. This patch fixes this internal error, as well as normalize filters to behave similar to core indexes.
The logic in core Tarantool select is as follows.
nilcondition in index select is an absence of condition, thus all data is returned disregarding the condition (condition may affect the order).box.NULLcondition is a condition for the null value -- in case of EQ, only records with null index value are returned, in case of GT, all non-null values are returned since nulls are in the beginning of an index and so on.nils andbox.NULLs in tuple are both satisfybox.NULLequity.After this patch,
nilfilter condition is treated as no condition. This is a breaking change since conditions for'>'and'<'operator withniloperand had resulted with empty response before this patch. But since it was inconsistent with scanning index conditions and wasn't intentional, we change it here.Closes #422