use of self.column instead of self.db_column #11
Conversation
This file contains 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
iamahuman
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 16, 2021
iamahuman
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 16, 2021
Supercedes disqus#11. Fixes: eea01c6 (use the db_column attribute of a model field if set https://docs.djangoproject.com/en/dev/ref/models/fields/#db-column, 2012-01-05)
iamahuman
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 16, 2021
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 bypasses 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
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 16, 2021
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
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 16, 2021
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
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 16, 2021
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
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 16, 2021
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
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 18, 2021
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
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 18, 2021
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
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 18, 2021
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
added a commit
to iamahuman/django-bitfield
that referenced
this pull request
Jan 18, 2021
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.
patelpritesh
pushed a commit
to Trendlyne-technologies/django-bitfield
that referenced
this pull request
Oct 29, 2021
…g in older versions of Django. Closes disqusGH-11.
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.
Reading Pro Django I saw that a self.column exists so it's better to use it instead of recalculating it