>
> 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.
Yes - sorry for not unclear, this is what I meant. We don't need to
*require* the output field, but it will be necessary in some cases.
Bike shed: perhaps output_field is a better name than base_field, to match
expressions, and since it's not the base/"source" field for the expression,
but where the output/result of the expression is stored.
On Wed, Apr 13, 2022 at 2:48 PM charettes <charett...@gmail.com> wrote:
> > 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
> <https://groups.google.com/d/msgid/django-developers/3887ba35-fa4d-4360-badb-58097c57c59bn%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/CAMyDDM1Y8tidBwiU-T1tV-PkZhJxgCQRgcAQA1Yd5qJBZA2F0Q%40mail.gmail.com.
