As I've said on other threads, fields can't define extra operations - they
must do everything inside the SchemaEditor's add_field method (operations
are not the only thing which calls the SchemaEditor, in theory). Ticket
#22022 (https://code.djangoproject.com/ticket/22022) covers this - there'll
be some kind of field method that SchemaEditor looks for for its extra SQL
to run.
I agree, though, Anssi - if we have that in there then it's a lot easier.
Andrew
On Wed, Apr 2, 2014 at 7:10 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>wrote:
> On Wednesday, April 2, 2014 6:58:22 AM UTC+3, schinckel wrote:
>
>> For that reason, I wouldn't be the fan of the exploded syntax you've
>>> given; I think I'd rather just be able to supply a list of strings for my
>>> constraints that are SQL themselves; there's no real benefit to abstraction
>>> here, and removing it doubtless removes a lot of code and bugs. Otherwise,
>>> I think I'd be +0.
>>>
>>
>> Pushing on from there: it's not much work from doing "constraints =
>> ('check start < finish',)" to just writing a RunSQL migration operation.
>> The exploded syntax was more me working things through late at night
>> anyway. And it seems like there's not really much else to do other than raw
>> SQL for exclude constraints.
>>
>> So, it's actually possible to do _most_ of what I want already - just
>> using a migration. The per-field check constraint could/should also be
>> implemented as a validator. Exclude constraints are another kettle of fish:
>> as I mentioned before, it's not actually possible to validate these
>> constraints without hitting the database, and even then that's not alway
>> enough. You still need to handle IntegrityErrors if an update between when
>> you checked and when you actually try to save causes a conflict.
>>
>
> I'd concentrate effort on allowing fields to define arbitrary extra DDL
> for migrations. Other use cases for extra migrations for fields are custom
> index types and ability to do "CREATE EXTENSION some_extension" (for
> example hstore) when needed. Optimally the latter would be best done with a
> dependency to another migration so that CREATE EXTENSION will be ran only
> once, but doing CREATE EXTENSION IF NOT EXISTS is good enough.
>
> The basic idea for this is to allow fields to give extra migration steps.
> Probably this is best done with get_extra_migrations() method that return a
> list of extra migration operations (instances of MigrationOperation class).
> I am not exactly sure how each migration operation should look like, but at
> the least it must be able to produce the needed SQL (per backend) for the
> step. Also, I don't know the migrations portion of the ORM that well, so it
> might be that a list of extra migration operation instances per field isn't
> sensible.
>
> If get_extra_migrations() was available, then doing CHECK constraints and
> custom index definitions should be a lot easier. If one wants to write a
> field with EXCLUDE constraint in their project (or as 3rd party app) that
> should be possible, too.
>
> - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/2c47e14e-3a46-49c0-8d08-e181f80dd058%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/2c47e14e-3a46-49c0-8d08-e181f80dd058%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" 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/CAFwN1uqifCrGKa0xnMAh_bxL%2B%2B5qahQOevwdYg%2B8ihJibCvXnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
