tests: Use direct values instead of raw SQL #117
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_value
and 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.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 theBitFieldCreator
descriptor's__set__
method is bypassed and the value is assigned unchanged.