I was assuming that the Index class would be responsible for
generating the whole SQL. Seems like this isn't the case.
I assumed something like this would happen when a new index is added:
1. User adds a new BTreeIndex to a model
2. The makemigrations command detects a change and creates a
migration file with AddIndex operation
3. The migrate command calls BTreeIndex.database_forwards, the
database_forwards method generates the needed SQL ('CREATE INDEX
foobar ON thetable(thecol)')
4. The migration framework runs the generated SQL
This way would let the BTreeIndex class generate the full SQL.
If I am not mistaken, the plan is to generate the SQL mostly in the
migration operations, that is the user can't alter the full SQL by
creating custom Index classes. So, #3 above would be replaced by the
AddIndex operation detecting changes in the BTreeIndex class and
generating the needed SQL. The main point is that the AddIndex
operation isn't under user control, so parts of the generated SQL is
essentially hard-coded into Django.
Giving users full control over the generated SQL would allow contrib
or 3rd party apps to create fully custom index classes for their
needs. The expressions/transforms/lookups approach has shown this is a
powerful approach. As an example, it is unlikely we will add BRIN
index support to Django core, but it could be added to
django.contrib.postgres.
It is worth considering if we could allow users to have full control
of the generated SQL. It might be a bit too much for one GSoC program,
so I'm fine with a decision to use the hard-coded approach.
- Anssi
On Sun, Mar 13, 2016 at 10:24 AM, akki <aksheshdo...@gmail.com> wrote:
>
>>
>> What about calling the attribute something like "constraints" similar to
>> how it's done in SQLAlchemy [1]? For now the attribute can just contain a
>> list of Index() instances but that would also lay grounds for supporting
>> check constraints and other related table level options.
>
> Since we are just allowing instances of Index class and it's subclasses
> right now, I don't think there is much gain in naming it "constraints". It
> might even confuse the user.
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/090de3a1-63da-4897-9bb6-a7997a9b9610%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CALMtK1Egv1R7XOA-bG9RPM4iRsCY88szCE7KPj%3Dzmq%3DGFJeBGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
