On 6/20/12 3:33 AM, Melvyn Sopacua wrote:
On 20-6-2012 0:49, André Pang wrote:
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.
Because this would break consistency. Your application would behave
differently for different backends, which is rather confusing.
There is great value in enforcing data integrity at the database level.
Django does a beautiful job of mapping code to database definitions and
in some sense that might distract from the traditional approach of
defining databases and integrity independent of the application. imho
one should not feel shy about adding additional constraints or checks at
the database level. If your app enforces everything you hope it does
then your db constraints will never be triggered, and if your app has a
hole in it then your database will catch it and keep bad data from
polluting it.
There are other ways around this too: in Postgres at least you can
define a rule which would substitute a null for a blank on data entry.
Breaking consistency between backends sounds bad, but designing to the
least common denominator is not a requirement. This may just suggest
that other backends which can distinguish between nulls and zero-length
strings would be a better choice for some apps ;)
hth
- Tom
--
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.
