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
On Fri, Aug 28, 2015 at 7:30 AM, Andrew Godwin <and...@aeracode.org> wrote:
> 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.
>>>> 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.
>
>
> --
> 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.
--
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/CALMtK1GR6CH%3D1E1z3x6UVHBamzKfgCCDDUQymaHvfyFSg72UXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
