Regarding custom sentinels for values vs custom sentinels for missing values:

The added complication in this case is migrations, and migrations that support 
multiple Django versions, as is common in 3rd party apps. I haven't thought 
through the implications, but it is vital to do so, because getting it wrong 
can seriously hurt the adoption of a feature, and even the adoption of a new 
version of Django.

It may not be an option to say "for compatibility generate migrations using the 
lowest supported Django versions", because sometimes old Django versions have 
bugs that prevent migration generation. 

We also need to consider the potential need for several different sentinel 
values e.g. "unlimited" vs "database defined max length". 

Luke 

On 28 February 2016 14:38:40 GMT+00:00, "Loïc Bistuer" <loic.bist...@gmail.com> 
wrote:
>There is a precedent to this (although it seems to happen at startup
>time rather than save time), we loop through all the connections and
>check that max_length has a value supported by their backend:
>https://github.com/django/django/blob/master/django/db/backends/mysql/validation.py.
>
>I don’t think we need to create a new sentinel value to mean
>“unlimited” when `max_length=None` works well semantically, if we want
>to keep the `max_length` value explicit we can just use `NOT_PROVIDED`
>as the kwarg default value. It is backwards compatible since
>`max_length=None` currently issues an error.
>
>Regarding the switch to a default value of 120 or so, I don’t have a
>strong opinion against it, but I think it’s an orthogonal problem to
>supporting unlimited varchar on backends that can handle it.
>
>> On Feb 28, 2016, at 6:50 PM, Florian Apolloner
><f.apollo...@gmail.com> wrote:
>> 
>> I do not see how blowing up on save is a good idea (especially not if
>we ran model validation before). We do not do that for MySQL (at least
>not if your project is configured properly, leaving issues with utf8mb4
>out for now) since our model form validation is able to use the
>supplied max_length to inform the user that the data is invalid
>__before__ save.
>
>-- 
>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 post to this group, send email to
>django-developers@googlegroups.com.
>Visit this group at https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/663F6FA1-1D09-4A21-928A-836157386253%40gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my phone 

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F5159BD5-23CD-46EF-92A7-EF10BCCE7890%40cantab.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to