models: blank, null and oracle

[Evgeniy Ivanov]

Hi!

I have such code:
"name = models.CharField(max_length=32)".
Thus "blank=False and null=False" should be applied. But in DB this
attr is nullable, and since oracle stores empty strings as null
attribute created wrongly (' "NAME " NVARCHAR2 (32) , ').

Should I file a bug?

P.S. I posted to users list occasionally, sorry for doubling.

[Ian Kelly]

On Thu, Mar 5, 2009 at 8:37 AM, Evgeniy Ivanov <lolkaa...@gmail.com> wrote:
>
> Hi!
>
> I have such code:
> "name = models.CharField(max_length=32)".
> Thus "blank=False and null=False" should be applied. But in DB this
> attr is nullable, and since oracle stores empty strings as null
> attribute created wrongly (' "NAME " NVARCHAR2 (32) , ').
>
> Should I file a bug?

This is intentional. CharFields are forced to have null=True when
using Oracle. The reason for this is that you're still allowed to
store the empty string in such a field, even when blank=False.

Regards,
Ian

[Evgeniy Ivanov]

On Mar 5, 6:57 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:

> On Thu, Mar 5, 2009 at 8:37 AM, Evgeniy Ivanov <lolkaanti...@gmail.com> wrote:
>
> > Hi!
>
> > I have such code:
> > "name = models.CharField(max_length=32)".
> > Thus "blank=False and null=False" should be applied. But in DB this
> > attr is nullable, and since oracle stores empty strings as null
> > attribute created wrongly (' "NAME " NVARCHAR2 (32) , ').
>
> > Should I file a bug?
>
> This is intentional.  CharFields are forced to have null=True when
> using Oracle.  The reason for this is that you're still allowed to
> store the empty string in such a field, even when blank=False.
>

Sorry, I'm not sure I understand the reason. Why do I need to be able
to store empty strings for CharFields, that marked as required? In
docs written, that default values for null and blank are False and
also "When using the Oracle database backend, the null=True option
will be coerced for string-based fields that can blank, and the value
NULL will be stored to denote the empty string". But in our case
string-based field's can't blank.

[Ian Kelly]

Thanks for pointing that out, because that documentation is wrong.
The Oracle notes
(http://docs.djangoproject.com/en/dev/ref/databases/#null-and-empty-strings)
have it correct, where it says it "coerces the null=True option on
fields that permit the empty string as a value," which is not the same
thing as fields with blank=True. The 'blank' option only affects
admin validation, not what can actually be stored in the field. It
does not prevent you from explicitly assigning an empty string to the
field. Since the other backends will allow this without a hiccup, we
coerce the option in order to also allow it for compatibility.

There is actually no way to prevent Django from doing this. If you
really want the column to be not null, you can alter the table
manually. But be aware that you effectively lose that constraint if
you ever port the app to a different backend.

Regards,
Ian

[Evgeniy Ivanov]

On Mar 5, 11:08 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:

> On Thu, Mar 5, 2009 at 11:57 AM, Evgeniy Ivanov <lolkaanti...@gmail.com> wrote:
>
> > On Mar 5, 6:57 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> >> On Thu, Mar 5, 2009 at 8:37 AM, Evgeniy Ivanov <lolkaanti...@gmail.com> wrote:
>
> >> > Hi!
>
> >> > I have such code:
> >> > "name = models.CharField(max_length=32)".
> >> > Thus "blank=False and null=False" should be applied. But in DB this
> >> > attr is nullable, and since oracle stores empty strings as null
> >> > attribute created wrongly (' "NAME " NVARCHAR2 (32) , ').
>
> >> > Should I file a bug?
>
> >> This is intentional.  CharFields are forced to have null=True when
> >> using Oracle.  The reason for this is that you're still allowed to
> >> store the empty string in such a field, even when blank=False.
>
> > Sorry, I'm not sure I understand the reason. Why do I need to be able
> > to store empty strings for CharFields, that marked as required? In
> > docs written, that default values for null and blank are False and
> > also "When using the Oracle database backend, the null=True option
> > will be coerced for string-based fields that can blank, and the value
> > NULL will be stored to denote the empty string". But in our case
> > string-based field's can't blank.
>
> Thanks for pointing that out, because that documentation is wrong.
> The Oracle notes

> (http://docs.djangoproject.com/en/dev/ref/databases/#null-and-empty-st...)

> have it correct, where it says it "coerces the null=True option on
> fields that permit the empty string as a value," which is not the same
> thing as fields with blank=True.  The 'blank' option only affects
> admin validation, not what can actually be stored in the field.

I understand the difference :)

> It
> does not prevent you from explicitly assigning an empty string to the
> field.  Since the other backends will allow this without a hiccup, we
> coerce the option in order to also allow it for compatibility.

Now I understood. Thanks for explonation.

> There is actually no way to prevent Django from doing this.  If you
> really want the column to be not null, you can alter the table
> manually.  But be aware that you effectively lose that constraint if
> you ever port the app to a different backend.
>

I only dislike the thing, that I can do:
"insert into auth_user (id, LAST_LOGIN, DATE_JOINED)
values ('222', '04-MAR-09 08.58.28.748832 AM', '04-MAR-09
08.58.28.748832 AM');"
for auth.User for example. It's not pretty to have such holes on the
database level.