>
>
> 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
Hi Gavin,
On 08/27/2015 07:27 PM, Gavin Wahl wrote:
> 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,
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
On Friday, August 28, 2015 at 2:29:13 AM UTC-4, Gavin Wahl wrote:
>
> > making lookups and transforms work on Python
> side,
> 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 fi
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 wh
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 h
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 dr
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.
On Friday, August 28, 2015 at 11:37:55 AM UTC+9:30, Andrew Godwin wrote:
>
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
