| Age | Commit message (Collapse) | Author |
|
get_placeholder_sql.
The lack of ability of the get_placeholder call chain to return SQL and
parameters separated so they can be mogrified by the backend at execution time
forced implementations to dangerously interpolate potentially user controlled
values.
The get_placeholder_sql name was chosen due to its proximity to the previous
method, but other options such as Field.as_sql were considered but ultimately
rejected due to its different input signature compared to Expression.as_sql
that might have lead to confusion.
There is a lot of overlap between what Field.get_db_prep_value and
get_placeholder_sql do but folding the latter in the former would require
changing its return signature to return expression which is a way more invasive
change than what is proposed here.
Given we always call get_db_prep_value it might still be an avenue worth
exploring in the future to offer a publicly documented interface to allow field
to take an active part in the compilation chain.
Thanks Jacob for the review.
|
|
|
|
installed when using its features.
Added postgres.E005 to validate 'django.contrib.postgres' is in INSTALLED_APPS
when using:
* PostgreSQL-specific fields (ArrayField, HStoreField, range fields, SearchVectorField),
* PostgreSQL indexes (PostgresIndex and all subclasses), and
* ExclusionConstraint
The check provides immediate feedback during system checks rather than failing
later with obscure runtime and database errors.
Thanks to Simon Charette and Sarah Boyce for reviews.
|
|
Thanks Simon Charette, Tim Graham, and Adam Johnson for reviews.
Co-authored-by: Florian Apolloner <florian@apolloner.eu>
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
|
|
|
|
Bug in 667105877e6723c6985399803a364848891513cc.
|
|
|
|
|
|
range fields.
|
|
This required implementing a limited form of dynamic dispatch to combine
expressions with numerical output. Refs #26355 should eventually provide
a better interface for that.
|
|
django.db.models.lookups.PostgresOperatorLookup.
|
|
SmallIntegerField, and DecimalField.
|
|
BigIntegerField.
It's already registered for IntegerField.
|
|
for RangeFields.
Co-Authored-By: Mariusz Felisiak <felisiak.mariusz@gmail.com>
|
|
lists and tuples.
|
|
|
|
Thanks to Nick Pope and Mariusz Felisiak for review.
Co-Authored-By: Mariusz Felisiak <felisiak.mariusz@gmail.com>
|
|
|
|
|
|
|
|
when the right hand side is the same type.
Thanks Tilman Koschnick for the report and initial patch.
Thanks Carlton Gibson the review.
Regression in 6b048b364ca1e0e56a0d3815bf2be33ac9998355.
|
|
|
|
Thanks Mariusz Felisiak and Tim Graham for polishing the patch.
|
|
|
|
Thanks Tim Graham and Simon Charette for the reviews.
|
|
Thanks Tim Graham for completing the initial patch.
|
|
Used the same test and fix as in #25867.
This required initializing base_field in RangeField.__init__,
not when setting the attribute.
|
|
Also added tests for HStoreField and JSONField.
Thanks Aleksey Bukin for the report and Tim Graham for the initial patch and
the review.
|
|
|
|
The method duplicates the functionality of Field.value_from_object()
and has the additional downside of being a privately named public
API method.
|
|
Note this means the serialization of e.g. IntegerRangeField now has
strings for lower and upper, so use to_python when they came back in
(same behaviour as ArrayField, hopefully, from where I also got the
set_attributes_from_name function).
|
|
Use the DjangoJSONEncoder so that datetime and date are encoded
appropriately.
|
|
Provide `contained_by` lookups for the equivalent single valued fields
related to the range field types. This acts as the opposite direction to
rangefield__contains.
With thanks to schinckel for the idea and initial tests.
|
|
|
|
Added support for PostgreSQL range types to contrib.postgres.
- 5 new model fields
- 4 new form fields
- New validators
- Uses psycopg2's range type implementation in python
|