On Wednesday, April 2, 2014 4:09:37 AM UTC+5:30, simonb wrote: > > Hi > > Just FYI: back in 2007 GSOC there was a project to add constraints. The > syntax was as follows: >
The code is at https://github.com/theju/django-check-constraints/ I doubt it works as is after the SQL compiler changes. It worked well on Postgres and SQLite. MySQL doesn't seem to support check constraints as of date. > > class Manufacturer(models.Model): > mfg_name = models.CharField(maxlength=50) > car_sale_start = models.DateField() > car_sale_end = models.DateField() > quantity_sold = models.IntegerField() > car_price = models.IntegerField() > > class Meta: > constraints = ( > ("check_name”, Check(mfg_name__like = 'Merc*')), > ("check_date”, Check(car_sale_start__between = [date(2007,1,1), > date(2008,1,1)])), > ("check_end_date”, Check(car_sale_end__gte = 'car_sale_start')), > ("check_quantity”, Check(quantity_sold__gte = 0)), > ("check_price”, Check(car_price__between = [0, 10000])), > ) > > > So a list of constraint name and a Check() pairs. I think the idea was > that Check() could be ANDd or ORd together a bit like the Q() object. > > It worked with Postgres AFAIR. > > Simon > > > > On Tue, Apr 1, 2014 at 7:07 PM, schinckel <ma...@schinckel.net<javascript:> > > wrote: > >> Some years ago, I discussed adding database-level check constraints into >> django: >> https://groups.google.com/forum/#!topic/django-developers/OJN5kpcseAg >> >> There is also an issue: https://code.djangoproject.com/ticket/11964 >> >> I'm thinking about revisiting this, and wanted to get some discussion >> going about if this is a viable thing to do, and what it might look like. >> >> >> Django already uses check constraints with PositiveIntegerField and >> friends, and at first blush I thought we might be able to co-opt some of >> that (indeed, I've got an internal monkey-patch that does, with some level >> of success). However, other than the fact there is already a >> 'sql_create_check' string, the actual python code that creates the check >> constraint probably isn't that usable in this context. Also, I like the >> idea of having more complex constraints (postgres has EXCLUDE constraints, >> but I don't know if there is an equivalent for other backends). >> >> >> The approach that I am thinking of could see a syntax similar to: >> >> >> class MyModel(models.Model): >> start = models.DateField() >> finish = models.DateField(constraints=[('check', '> start')]) >> user = models.ForeignKey('auth.User') >> >> This maps directly to creating a check constraint on the table: >> >> ALTER TABLE "myapp_mymodel" ADD CONSTRAINT CHECK (finish > start) >> >> And, on the same model, a more complex constraint could look like: >> >> >> class Meta: >> constraints = [ >> ('exclude', [ >> ('overlaps', ['start','finish']), >> ('equal', 'user') >> ]) >> ] >> >> I'm still unsure of the best way to describe this: it's supposed to mean: >> >> ALTER TABLE "myapp_mymodel" ADD EXCLUDE USING gist >> (daterange(start, finish) WITH &&, user_id WITH =) >> >> (but the python syntax is obviously immaterial at this stage). >> >> >> Obviously, we can't just rely on the database to do the validation for >> us: it will just raise DatabaseErrors when something fails to validate >> anyway, so we would want to handle this stuff in django's validation >> framework. >> >> One possibility, at least with the field-based check constraint, would be >> to automatically add a field validator in the case of a CHECK constraint, >> however in the case of an EXCLUDE constraint, we can't really validate >> _without_ hitting the database. Does this mean we should treat EXCLUDE-type >> constraints as something that is beyond the scope of Django? >> >> >> >> With the new migrations framework, it's actually trivial to write a >> migration to add this type of constraint (or the check constraint), and a >> pre_save signal handler in conjunction with that would get 90% of the way, >> but it's still going to be open to a race condition anyway - the only way >> to actually do that is to try to save the object and see what the database >> says. >> >> >> So, I guess I'm asking: is it worth pursuing this further, either in part >> or full? >> >> Matt. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to >> django-d...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/250ed272-198a-478f-b2ce-920afcf533a2%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/250ed272-198a-478f-b2ce-920afcf533a2%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f25d2f5d-734a-4c7e-bee8-3573ac72c529%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
