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
On Thu, Aug 27, 2015 at 9:25 PM, Gavin Wahl <gavinw...@gmail.com> wrote:
> 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> 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.
>>> 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
>>> <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
> <https://groups.google.com/d/msgid/django-developers/d8db8897-93f6-43e8-aa13-563fafa6a451%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 (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/CAFwN1uqtFQBwsXE2BpVCpqF4OQe8qO0-yjXSRyOmCf%2B70LY5Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
