#34944: Missing or misinferred attributes in output fields of generated fields
-------------------------------------+-------------------------------------
Reporter: Paolo Melchiorre | Owner: Om Dahale
Type: Bug | Status: assigned
Component: Database layer | Version: 5.0
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: field, database, | Triage Stage: Accepted
generated, output_field |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Om Dahale):
Replying to [comment:5 David Sanders]:
> Hm I think there are 2 tickets here… or at least 2 PRs. Perhaps forum
discussion is required but I don't think we ought to go down the route of
trying to make `resolve_expression()` smart enough to determine that
concat'ing 2 varchars means we need to add the max-lengths together –
there may be a can of worms here since expressions could be ever so
complex? 🤔
>
> We definitely need to fix the broken "None" in the DDL 👍
>
> > Always require specifying the output field (except when you are sure
that the extracted type cannot generate error situations?)
>
> Perhaps 👍 "Explicit is better than implicit" and all that, though I
think that documenting "For complex expressions consider always declaring
an output_field" is a nice option.
>
> I'm keen to hear Mariusz & Lily's thoughts.
So shall I continue my work on the 2 points given above?
--
Ticket URL: <https://code.djangoproject.com/ticket/34944#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018ba8f482ad-0a8f267c-7f87-4fb4-85db-c3830e2ad451-000000%40eu-central-1.amazonses.com.
