> 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.
On Thu, Aug 27, 2015 at 11:47 PM, Anssi Kääriäinen <akaar...@gmail.com>
wrote:
> 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 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-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.
>
--
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/CACPudh0vkDzNPgwmzSTs9g6-vVtYJhR32BN2HdWXMan8LjMHXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
