#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 Paolo Melchiorre):

 Replying to [comment:14 Simon Charette]:
 > Resolving the `output_field` of combined expressions is a complex task
 that the ORM only has limited support for #26355, #31506, #33397, this is
 not a problem specific to `GenerateField`.

 Thanks for pointing this out, it helped me put this issue in the right
 perspective.

 > It is particularly tricky in the case of `varchar(x) + varchar(y)` as
 some backends restrict the allowed length of `varchar` (e.g. MySQL at 255)
 ...

 I would add that, to complicate things, the restrictions on the various
 types of fields also vary between different versions of the same database.

 > > The SQL code for the generated column has an automatically inferred
 max length of only 255 characters (varchar(255))
 >
 > ... In this particular case it's tempting to adjust the logic of
 `Concat._resolve_output_field` to be smarter and generate a
 `CharField(max_length=511)` but I suspect it might have unintended effect
 and not something we'd like to include in 5.0 at this point.
 > I suggest that we take the same approach here and expect the user to
 specify an explicit `output_field`.

 I totally agree, and thanks for rephrasing my initial proposal more
 clearly.

 > For the second part of the problem, `CharField(None)`, I think that the
 addition of a check is in order. Adding a
 `GeneratedField._check_output_field` that simply delegates to
 `self.output_field.check(**kwargs)` seems like the way to go to catch all
 misuse of `output_field`.

 Thanks for pointing out this approach.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/34944#comment:18>
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/0107018badebdcb3-0e96fe23-de4b-4fe8-acad-aa1545c7a62d-000000%40eu-central-1.amazonses.com.

Reply via email to