Check Constraints for databases that support them
I'm very interested in the idea of expanding the database level
constraints that can be supplied to a database schema, and also
automatically apply the same constraints to the model/view in django.
The various backends that support them, I believe already apply such
constraints for PositiveIntegerField() and so on.
I would like to see the ability to define extra constraints as part of
the model definition, and have these applied in a similar manner to
the unique and unique_together constraints.
I am more familiar with PostgreSQL than anything else, but I believe
the syntax I am about to propose will work in several databases.
Check constraints can be divided into two types: column level and
table level. With PostgreSQL, a column level constraint can reference
another column, but I would suggest that a constraint that does so
should be a table level constraint.
Column level constraints could be declared as a keyword argument to
the field constructor:
column = models.IntegerField(constraint='< 100')
Table level constraints could be declared as an attribute on the Meta
class of the model:
check_constraints = ('start < finish', )
Validation of the models should pick up when an incorrect constraint
has been declared. For instance, not using a valid operator ('# 100')
or not supplying a valid comparison value ('< 1e' for an IntegerField)
would be invalid column constraints, and comparing a Date to an
Integer would be an invalid table level constraint.
The code that should be generated would add "CHECK ('column' < 100)"
to the column definition in the first instance, and "CONSTRAINT
app_table_start_finish CHECK ('start' < 'finish')" to the table
definition in the second case.
I have already written code that fulfils these requirements, and some
tests for validation errors. I have also written additions to
BaseModelForm which validates according to the defined constraint(s).
At this stage, I have not allowed for more complicated relationships,
such as ('first < second + 65'), but this is planned.
Is there anyone else interested in this? Should I put this into a
ticket and attach my current diff?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Check Constraints for databases that support them
On Sep 26, 10:27 pm, Tim Chase wrote:
> > Is there anyone else interested in this?
>
> yes, I'd be interested in seeing some sort of database-level
> CHECK constraint as part of Django. I had been sitting on my
> thoughts until I see the GSoC work done on model-validation wend
> its way towards trunk. My hope had been to see model validation
> incorporate some DB-level CHECK constraints where feasible.
I did have a brief look at the django-check-constraint project on
google code, but it was overkill for what I needed.
> One of the other difficulties involves database expression
> differences. For the simple cases such as you suggest, it's not
> as bad as they're fairly standard. However, when functions are
> involved, each DB seems to have its own family of functions.
> E.g. if you want to assert the length of a string is 10
> characters ("len" vs. "strlen"?) or the time is during business
> hours ("hour(fieldname) between 8 and 17"...extracting
> time-portions varies across DB engines).
Yeah, for the time being I was only interested in simple cases.
Comparing against a static value in the case of column constraints,
and comparing two columns in the table-level case. I don't even allow
for 'start < finish + 1' in the code I have written so far.
> I currently just add the CHECK constraints manually (well, in
> post-syncdb code). Having them in a declarative fashion would
> help keep them in the right place.
Not to mention that it will allow the same code to control the db-
level constraint, and the django validation (admin, form). Which is
DRY, and one of the reasons I am moving projects to django.
I also looked a little bit at south, which I have just started using
for migrations. It doesn't have anything in there that is that
useful, other than raw SQL. Which can do those type of things, but it
is nicer to move into the declaration.
Matt.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Feature Request: Reinteract
On Nov 27, 10:07 pm, noel wrote: > I really love this application Reinteract. Its an enhancement to > Python Interactive Shell. And it would be lovely if I can use > Reinteract with manage.py shell. Have a look at bpython. I have a command set up where I can run ./manage.py bshell And I get a bpython shell with all of the models already imported. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: why last_login in django.contrib.auth.models.User cannot be null?
On Dec 15, 8:59 am, Sergiy Kuzmenko wrote: > I wonder if there is a particular reason why last_login field of is not > defined as "null=True"? It makes sense to me to have it as null which would > mean that the user never logged in. Could there be any dependencies relying > on this field not being null? I came across one today: contrib.auth.tokens.PasswordResetTokenGenerator has a method _make_token_with_timestamp, which uses last_login to create the token. This means that if someone generates a password reset request, the token will be invalidated if that user then logs in. This could occur if a person creates password reset requests for a user that is not themself. Matt. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: why last_login in django.contrib.auth.models.User cannot be null?
On Dec 15, 8:59 am, Sergiy Kuzmenko wrote: > I wonder if there is a particular reason why last_login field of is not > defined as "null=True"? It makes sense to me to have it as null which would > mean that the user never logged in. Could there be any dependencies relying > on this field not being null? > What isn't clear is that this value must be after 1900: I had used a value of datetime(1,1,1,0,0) as "never logged in", but this fails with password reset. Matt. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
