tests: Use direct values instead of raw SQL - #117
Open
iamahuman wants to merge 1 commit into
Open
Conversation
iamahuman
force-pushed
the
test-no-direct-sql
branch
3 times, most recently
from
January 16, 2021 14:52
3fc4ef5 to
ded42f5
Compare
iamahuman
marked this pull request as draft
January 18, 2021 13:34
iamahuman
force-pushed
the
test-no-direct-sql
branch
from
January 18, 2021 13:38
ded42f5 to
e5be396
Compare
iamahuman
marked this pull request as ready for review
January 18, 2021 13:38
iamahuman
force-pushed
the
test-no-direct-sql
branch
2 times, most recently
from
January 18, 2021 13:53
e46df85 to
ea34e02
Compare
Supersedes disqus#11. In order to prevent (-1) from being masked by BitField.get_prep_value and converted to 15 (0xf), the test code uses a direct SQL statement. Its implementation has a few peculiarities that may be undesirable: - It uses an Django internal API, the Field.column attribute. Granted, this package already uses a lot of internal APIs, and Field.column is highly unlikely to change. However, in general using less internal APIs is better for future compatibility. - Using low-level API misses a lot of code paths that could have been tested. - Neither db_table nor db_column is escaped. In case we later incorporate tests involving pathological SQL object identifiers, we have to further use quote_name, which is not exactly public API either. Instead, we use models.Value() with an explicit output_field, which still avoids BitField.get_prep_value and inserts the value directly. Further, directly assign to __dict__ so that the BitFieldCreator descriptor's __set__ method is bypassed and the value is assigned unchanged.
iamahuman
force-pushed
the
test-no-direct-sql
branch
from
January 18, 2021 13:55
ea34e02 to
cf96c2d
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Supersedes #11.
In order to prevent (-1) from being masked by
BitField.get_prep_valueand converted to15(0xf), the test code uses a direct SQL statement. Its implementation has a few peculiarities that may be undesirable:It uses an Django internal API, the
Field.columnattribute. Granted, this package already uses a lot of internal APIs, and Field.column is highly unlikely to change. However, in general using less internal APIs is better for future compatibility.Using low-level API misses a lot of code paths that could have been tested.
Neither db_table nor db_column is escaped. In case we later incorporate tests involving pathological SQL object identifiers, we have to further use quote_name, which is not exactly public API either.
Instead, we use models.Value() with an explicit output_field, which still avoids BitField.get_prep_value and inserts the value directly.
Further, directly assign to
__dict__so that theBitFieldCreatordescriptor's__set__method is bypassed and the value is assigned unchanged.