Would you be able to support partial indexes as well? On Tuesday, March 8, 2016 at 7:46:02 AM UTC-7, akki wrote: > > Hi > > My name is Akshesh Doshi (akki). I am a student at Indian Institute Of > Technology, Roorkee (IITR). I have been contributing to Django > <https://github.com/django/django/pulls/akki> for quite some time now and > my experience has been really great till now. I found the community to be > very welcoming and have learnt a lot in this period of time. > > With this spirit I would like to work on the idea of "Custom Indexes" > <https://code.djangoproject.com/wiki/SummerOfCode2016#Customindexes> and > extend it as my proposal for Google Summer of Code 2016 > <https://summerofcode.withgoogle.com/>. > > I have started preparing my proposal and here is the initial draft > <https://gist.github.com/akki/b438292c2c3cf199012f> of it. I would like > to hear your thoughts regarding this. Also I wanted to discuss some points > mentioned below. The timeline still needs work as I am still digging into > the code of expressions to see how we can use them in FunctionalIndex. Any > pointers/thoughts on that would be appreciated. > > Key points: > - Introduction to classed based indexes. > - Support for custom classes to db_index. > - Introduction of Meta.indexes. > - Allowing fields to specify their own index type. > - Support for a indexes/constraints API. > - Extend expressions into indexes. > - Bring spatial indexes under the hood. > > Points I would like to discuss: > 1) Would it be right to *create a IndexTogether class* (subclass of > Index) and internally translate Meta.index_together to it ? > This would allow something like - > class Meta: > indexes = [IndexTogether(['field1', 'field2'])] > I think this would let us keep a better track of any indexes > (including those by `index_together`) that are being created. > `Meta.index_together` would be internally translated to Meta.indexes. This > might also be followed by deprecation of `index_together` if we want. > > 2) > *Handling Unique constraints via indexes.* For handling of > constraints, I was thinking of creating a UniqueIndex class which would > handle any unique constraint on any column and allow other options like to > make it deferrable. > Right now fields with ``unique=True`` apply the unique constraints > by using both the UNIQUE constraint in the CREATE TABLE statement and by > creating an index for it. For example, in this model > <https://gist.github.com/akki/56b6c3cac56073c9bf4d>, multiple (repeating) > indexes are being generated for the `name` field (one by UNIQUE constraint, > 2 others manually, on postgresql). This takes more space and is also not > good performancewise. This situation can also be mitigated by keeping a > track of all unique constraints at only one place. > So I was thinking of bringing the unique constraint totally under > indexes. Maybe some `models.UniqueIndex()` could be used in meta.indexes to > add constraints ? Any thoughts on it ? > > > I had also prepared a DEP (based on an earlier DEP by Marc Tamlyn), which > is now a subset of this proposal. > > Regards > Akshesh Doshi > (akki) >
-- 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/8c3a0f04-4b2a-4c0e-87af-2b9d209681e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
