There are many places that expressions can extend to, and I think indexes
would make a really good candidate. There are a few things that need to
happen to make this work though.
- create meta.indexes to store { index_name: IndexType('field') }
- internally translate any db_index=True to the appropriate key: val in
above meta.indexes
- internally translate index_together into meta.indexes
- use compiler to generate the sql
- ensure that migrations handle these new indexes properly
I would also suggest that index names be queried to ensure we're not trying
to use existing names. Not sure if migrations already do this, but I seem
to remember something about not being able to track index names. Am I
totally off base?
This idea would actually make a really good GSoC (or similar..) project. Is
there much interest from the community in custom indexes?
On Sunday, 7 February 2016 22:11:59 UTC+11, Curtis Maloney wrote:
>
>
> So, in #django recently there was a discussion about adding an index on
> a date field for just the year.
>
> I know the idea was raised some time ago, and several ideas on the
> syntax were expressed. But most of that focused on different types of
> indices - not on indexing expressions.
>
> It occurred to me that with the recent advances in expression syntax, it
> should be fairly easy to add an indexes list to Meta to define complex
> expressions.
>
> Input?
>
> --
> C
>
--
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 [email protected].
To post to this group, send email to [email protected].
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/384535c0-e095-47a5-b73d-1c60649895c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
