The idea is to try to ensure that no empty strings make it to the
database, so you're not allowed to insert them into the database. You
can ensure this at the Django (ORM) layer right now with blank=True for
the admin or by checking the blank attribute manually in your own code,
but there's no database-level restriction, which is what I'm after.
In Oracle:
SQL> create table T (c nvarchar2(16) not null);
Table created.
SQL> insert into T values('hello');
1 row created.
SQL> insert into T values ('');
insert into T values ('')
*
ERROR at line 1:
ORA-01400: cannot insert NULL into ("T"."C")
On 6/18/2012 7:33 PM, Kurtis Mullins wrote:
I've read over this many a time -- never paid much attention because I
don't use Oracle:
https://docs.djangoproject.com/en/dev/ref/models/fields/#null
Anyways, if you don't allow NULL and you don't allow empty strings,
what are you going to put in there when there's nothing?
On Mon, Jun 18, 2012 at 7:59 PM, André Pang <andre.p...@gmail.com
<mailto:andre.p...@gmail.com>> wrote:
On Jun 18, 2012, at 4:05 PM, Ian wrote:
>> I'd assume that Django would only generate schemas where NULL
is allowed for fields where blank=True, and that fields where
blank=False would have "NOT NULL" included in the Oracle DDL.
>
> blank=True is a validation option, not a database option. A
field with blank=False can still have the empty string as a
possible value, and it can be stored like that in any of the other
backends; it's just not accepted by the admin site.
My mistake; I forgot that the blank attribute is an admin
validation option only.
> In this case it's mainly a cross-compatibility issue -- if an
app stores the empty string on a blank=False field in Postgres, it
should be able to do that when the backend is Oracle as well.
Gotcha: since Oracle uses NULL to denote empty strings, the Oracle
backend overrides Field.null to always be True.
What I'd like to do is (1) disallow NULLs, and (2) disallow empty
strings. It looks like there's no current way to do this with
Oracle since the backend overrides null to always be True, and
blank is an admin validation thing only.
I'm happy to make my own local subclass of CharField/TextField/etc
that has the behavior that I'd like; I'm guessing that the Django
team don't intend to change this behavior. (It seems that the
only way to do this would be to change the semantics of null,
which seems foolhardy, or add yet another option, which would be
quite confusing with null and blank already.)
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
<mailto:django-users%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
