Hi,
Oracle treats empty strings and NULLs in the same way, that's why we
had to decide on some workaround that will cover both python's (other Dbs')
cases i.e. NULLs and "" (see
https://docs.djangoproject.com/en/2.1/ref/databases/#null-and-empty-strings).
I don't see much value in changing current behavior from *"empty strings
always"* to *"NULLs always"*, because it will be backward incompatible and
IMO it doesn't change anything, still non-Oracle people will be surprised
by this behavior.
I agree that creating a *"NOT NULL" *constraint in case when "null=False*"
*(or even "blank=False") may be a helpful addition to the current behavior
but I'm not sure how doable it is if we take into account migration of
existing projects.
Best,
Mariusz
W dniu czwartek, 8 listopada 2018 18:33:52 UTC+1 użytkownik
vaf...@exscientia.co.uk napisał:
>
> Hi Florian,
>
> Yes you are correct, backwards compatibility would break with this change.
> As Django already mimics the required checks in middleware for nulls, only
> difference I can see going forward would be that newly inserted blank
> strings would be read back back as None, instead of '' if nulls are
> allowed. And where nulls are not allowed, neither would make it into the db.
>
> Look forward to hearing your thoughts Felix.
>
> Many Thanks,
> Vackar
>
> On Thursday, 8 November 2018 17:06:05 UTC, Florian Apolloner wrote:
>>
>> Hi Vackar,
>>
>> Thank you, now we are getting somewhere!
>>
>> On Thursday, November 8, 2018 at 5:36:53 PM UTC+1,
>> vaf...@exscientia.co.uk wrote:
>>>
>>> My main concern currently is that required fields are not enforced at
>>> the db level, which makes using it with other clients difficult. I would
>>> much prefer that constraints be added, and accept that empty strings cannot
>>> be inserted into required columns.
>>>
>>
>> Okay, now I get you. I have no strong feelings how our oracle backend
>> should behave here; other than your suggested change would be (highly?)
>> backwards incompatible and that alone might prevent it from getting merged.
>> Maybe Felix can chime in here with his oracle knowledge.
>>
>> FWIW, Django has quite a few places where it does stuff in the framework
>> itself instead of at the database level. Examples include the handling of
>> database default values (we don't, defaults are in the application, even
>> for simple integers and strings) as well as handling of cascades on
>> deletes. If one cannot live with those issues, it is imo currently best to
>> manage the database independent from Django. We are certainly open to
>> improving in those areas though.
>>
>> Cheers,
>> Florian
>>
>>
>>
--
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/403d5d50-660b-426c-a911-579d82273259%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
