CHECK Constraints and migrations

[Gavin Wahl]

I'm interested in writing a third-party app that allows users to declaratively write check constraints and have them automatically be added and removed by migrations. I'm envisioning being able to attach a list of Q objects to your model, something like:

    class Meta:

        checks = [

            Q(end_date__isnull=True) | Q(end_date__gt=F('start_date'))

        ]

Now that we have migrations, formalized Meta, and custom lookups, is it possible for a third-party app to manage this seamlessly?

I'm having trouble figuring out where it could hook in to migrations to detect changes to the check constraints, and automatically generate the migrations with operations to update the constraints. What code I should be reading to figure out how to do it?

[Andrew Godwin]

Hi Gavin,

Hooking into the migration autodetector is currently not really possible - it's quite inextensible, which is something I'd love to get ironed out in the long term but isn't really possible right now to modify it from third-party code.

You can, however, supply custom migration Operation classes that people could put into their migrations manually, or potentially have some other way of outputting those migration files with operations in them (a lot of the code to write them out is re-useable). Hopefully someone else has a better idea!

Andrew

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CACPudh1gRB_Jov_bH-maDGr4EBRugFuV3Y%2BBzYM9w0yyki7zkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[schinckel]

That's the approach I've used: either have a migration operation that you can run (included in a 3rd party or local app), or a management command that generates a migration file with the relevant custom operations.

Matt.

[Gavin Wahl]

That's too bad. I don't think it's really worth it unless the experience works seamlessly, because if I'm going to write a migration manually I might as well just use a RunSQL. I did have another slightly hacky idea that might work. Can custom Fields specify the operations used to create and drop them? It might then be possible to write a pseudo-field called 'Check':

    class FooModel(models.Model):

        # ...

        check_ends_after_start = Check(Q(end_date__isnull=True) | Q(end_date__gt=F('start_date')))

That instead of adding a column called ends_after_start, it would add a constraint.

Do you think it's possible for anyone besides you to work on making the migration framework more extensible? I'm interested in contributing in this area.

[Andrew Godwin]

No, fields can't really specify any of the SQL used to make/update/delete them (partially as the SQL is heavily dependent on the database backend, and Django traditionally has the fields as the database-agnostic bit and the backends as the specific bit). All they can do is supply a db_type, which has to fit in the space a type would go for ADD COLUMN, etc. (that's how contrib.postgres has its fields work, for example).

I know that Marc Tamlyn was looking into this for some of his PostgreSQL stuff, and other people have floated some ideas around letting fields have more control over migration stuff too - they may be able to chime in when we get to a sensible time in Europe on this.

I'm definitely far from the only person who can work on fixing up the migration stuff; in fact, I haven't done much to it at all recently and it's been all other people, so if you think you want to take a stab at it, you're more than welcome, and I'm more than happy to review patches against migrations.

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d8db8897-93f6-43e8-aa13-563fafa6a451%40googlegroups.com.

[Anssi Kääriäinen]

I recall another idea that would work very well with model level
Q-object based checks: making lookups and transforms work on Python
side, too. Then, when you supply a check "ends_after_starts", we
could both add it as a database level constraint, and also validate
the constraint on Python side when altering data.

I think it is a really good idea to add more control to Fields over
what migrations they generate, but unfortunately I don't have time nor
expertise to work on this.

- Anssi

> https://groups.google.com/d/msgid/django-developers/CAFwN1uqtFQBwsXE2BpVCpqF4OQe8qO0-yjXSRyOmCf%2B70LY5Kw%40mail.gmail.com.

[Gavin Wahl]

> making lookups and transforms work on Python

side, too. Then, when you supply a check  "ends_after_starts", we

could both add it as a database level constraint, and also validate

the constraint on Python side when altering data.

Yep, that's my plan. Just have to figure out the migration stuff first.

You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/Yy7mgoa7vdM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@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/CALMtK1GR6CH%3D1E1z3x6UVHBamzKfgCCDDUQymaHvfyFSg72UXA%40mail.gmail.com.

[Tim Graham]

Not sure that it has any useful info at this point, but there is an old ticket about adding support for CHECK constraints here: https://code.djangoproject.com/ticket/11964

[Carl Meyer]

Hi Gavin,

Not to take away from the value of working on making
migration-extensions more accessible to third-party code (I think that
would be great), but have you considered just doing this work in core? I
would guess there'd be strong support from the core team for having a
check-constraints feature in Django (I'm certainly in favor).

Carl

[Andrew Godwin]

Not to take away from the value of working on making
migration-extensions more accessible to third-party code (I think that
would be great), but have you considered just doing this work in core? I
would guess there'd be strong support from the core team for having a
check-constraints feature in Django (I'm certainly in favor).

For the record, I am also in favour of this.

Andrew