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.
On Thursday, August 27, 2015 at 8:07:55 PM UTC-6, 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 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
>
> On Thu, Aug 27, 2015 at 6:27 PM, Gavin Wahl <gavi...@gmail.com
> <javascript:>> 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, 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?
>>
>> --
>> 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 <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/CACPudh1gRB_Jov_bH-maDGr4EBRugFuV3Y%2BBzYM9w0yyki7zkg%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/django-developers/CACPudh1gRB_Jov_bH-maDGr4EBRugFuV3Y%2BBzYM9w0yyki7zkg%40mail.gmail.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 (Contributions to Django itself)" 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/d8db8897-93f6-43e8-aa13-563fafa6a451%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
