> Is it necessary to take a base field? Can we not determine the output
field type for some kinds of expression? e.g. F("some_integer_field") + 1
can be assumed to have output field type IntegerField.
It should be possible by simply accessing the `output_field` property of
the provided expression once it's resolved yes.
e.g.
# Will crash as the output field of some_integer_field has not been
resolved.
(F("some_integer_field") + 1).output_field
# Will work as F resolved to a Col pointing at SomeModel.some_integer_field
(assuming it exists)
(F("some_integer_field") + 1).resolve_expression(Query(SomeModel),
allow_joins=False).output_field
But as Paolo demonstrate in his example I think we might want a distinct
separation between the column type and the expression used to generate the
value of this field if unless we want to force users to do gymnastics to
rely on type coercion.
For example, in the reported case the user would have to do
`GeneratedField(SearchVector('title'))` which would actually result in
`tsvector GENERATED ALWAYS AS *to_tsvector*(title)` STORED which is not
exactly the same. It's not an issue here but I wouldn't be surprised that
not being able to configured a generated field to generate a particular SQL
output might be problematic in some cases.
What about we make the expected signature `GeneratedField(expression,
base_field=None)` where a missing `base_field` defaults to
`expression.output_field`? That would allow the exact expected SQL to be
generated with `GeneratedField('title', base_field=SearchVectorField())` if
there's a requirement for it.
Cheers,
Simon
Le mercredi 13 avril 2022 à 07:09:38 UTC-4, m...@kye.id.au a écrit :
> I’d love to see this!
>
> Kye
> On 13 Apr 2022, 7:05 PM +0800, Mariusz Felisiak <felisiak...@gmail.com>,
> wrote:
>
> Related tickets:
>
> - https://code.djangoproject.com/ticket/31300: Add function-based virtual
> fields on PostgreSQL and Oracle.
> - https://code.djangoproject.com/ticket/31565: Support GENERATED ALWAYS
> columns for MySQL and PostgreSQ
>
> Related DEP:
>
> - https://github.com/django/deps/pull/39 - Refactor ORM with VirtualField
> and CompositeField
>
> and an accepted ticket for non-database backed calculated field (see
> discussion
> https://groups.google.com/g/django-developers/c/ADSuUUuZp3Q/m/eZGYZv74AQAJ
> ):
>
> - https://code.djangoproject.com/ticket/28822 - Add DBCalculatedField to
> model to annotate models automatically
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-develop...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5bf85475-4d97-4249-bd68-baf9906d9fffn%40googlegroups.com
>
> <https://groups.google.com/d/msgid/django-developers/5bf85475-4d97-4249-bd68-baf9906d9fffn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/3887ba35-fa4d-4360-badb-58097c57c59bn%40googlegroups.com.
