GSoC 2007: Check Constraints Update

[Thejaswi Puthraya]

Hello everyone,
It's been a good week, I have been able to make quite some progress
(about the quality of work, you'll have to comment).

Here is the brief procedure that I adopted to implement Check
constraints.
1) Created a Check field that inherits the Field Class and here I
wrote the various attributes and methods for it (like for cascading
check conditions etc). Currently this Check Field has been added in
the django.db.models.fields.__init__.py file (at the end) and I'll
move it onto a separate file soon.
2) All the SQL creation statements have been left to the management.py
(I haven't modified the code but only added my code in the
management.py). I have not added the SQL statements in the class
itself because of the discussion here
http://groups.google.com/group/django-developers/browse_thread/thread/6186dc6aa6e49ad/98cf3eef8cbad58e?lnk=gst&q=check&rnum=1#98cf3eef8cbad58e).
3) As of now, I have only tested the check constraints on Postgresql
database server (it might also work on SQLite). One small modification
that has to be done to get the constraints thing working is to add a
'CheckField' : None entry in the
django.db.backends.postgresql.creation.py file.

Problem:
The check constraints got added successfully (after a syncdb) but the
problem is when I go to the admin page and to the model's page in it,
I get an error (link for the error page here
http://thejaswi.puthraya.googlepages.com/error.html). This error
vanishes when I comment the check fields in the models.py. I don't
understand why the Check (pseudo) field is getting (trying to get)
rendered in the Admin section.

Caveat:
There is currently no way to verify that all of the CHECK constraints
are mutually exclusive. Care is required by the database designer.
(I don't think it is possible to implement it because Postgresql also
isn't sure of how this is to be handled.)

Presently I am placing the files (outside the Google Hosting) and will
upload them after I get comments and sanction from the group to go
ahead.

django.db.models.fields.__init__.py --> http://thejaswi.puthraya.googlepages.com/__init__.py
django.core.management.py -->
http://thejaswi.puthraya.googlepages.com/management.py
Insert a line in django.db.backends.postgresql.creation.py -->
"CheckField" : None

The 'like','between','upper' and 'lower' constraints haven't been
implemented as yet. That would be in the next phase of this project.

The Project is hosted on http://code.google.com/p/django-check-constraints
Features page is http://code.google.com/p/django-check-constraints/wiki/Features

Waiting for some constructive criticism.

PS: The next time I'll add more documentation to my work. (Totally
neglected it...extremely sorry).

Thanking You
Thejaswi Puthraya
http://thejuhyd.blogspot.com

[Justin Bronn]

Thejaswi,

> Problem:
> The check constraints got added successfully (after a syncdb) but the
> problem is when I go to the admin page and to the model's page in it,

> I get an error ... This error vanishes when I comment the check fields

> in the models.py. I don't understand why the Check (pseudo) field is
> getting (trying to get) rendered in the Admin section.

I think what's going on here is that since you decided to implement
your constraint checks as a field, django tries to retrieve the check
field on queries. Specifically, take a look at line 477 in
_get_sql_clause() from django/db/models/query.py:
http://code.djangoproject.com/browser/django/trunk/django/db/models/query.py#L477

The select statement is being constructed for every field in the the
model, as it does by default. However, when the query is run the
database cannot find that column and throws an error.

The model thinks check is a valid field because it is within the
_meta.fields attribute of the model. The check field gets added to
the _meta.fields model attribute when the contribute_to_class() method
(inherited from the Field base class) is called:
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L142

You could override the contribute_to_class() method in your Check
class definition to prevent this from happening, but then the SQL
would not be executed from management.py (since it increments over
_meta.fields). I'm at a loss for a solution right now, but I think
that's your problem. One idea is to place the check field in
different attribute in _meta (see django/db/models/options.py).

Regards,
-Justin