Re: Unneeded index created with unique=True and db_index=False in TextField

2015-04-15 Thread Some Developer
On 15/04/15 23:45, Kevin Christopher Henry wrote: This issue was the subject of https://code.djangoproject.com/ticket/24082. There, the accepted (but not implemented) solution is the same as suggested here: allowing the user to opt out of the creation of the additional index with

Re: Unneeded index created with unique=True and db_index=False in TextField

2015-04-15 Thread Kevin Christopher Henry
This issue was the subject of https://code.djangoproject.com/ticket/24082. There, the accepted (but not implemented) solution is the same as suggested here: allowing the user to opt out of the creation of the additional index with `db_index=False`. On Wednesday, April 15, 2015 at 2:11:25 PM

Re: Unneeded index created with unique=True and db_index=False in TextField

2015-04-15 Thread Some Developer
On 15/04/15 18:22, Tim Graham wrote: #19441 is the ticket where it was decided that unique=True implies a database index. The documentation says, "Note that when ``unique`` is ``True``, you don't need to specify `Field.db_index`, because ``unique`` implies the creation of an index."

Re: Unneeded index created with unique=True and db_index=False in TextField

2015-04-15 Thread Tim Graham
#19441 is the ticket where it was decided that unique=True implies a database index. The documentation says, "Note that when ``unique`` is ``True``, you don't need to specify`Field.db_index`, because ``unique`` implies the creation of an index." Unless we decide that is wrong, I think the

Re: Unneeded index created with unique=True and db_index=False in TextField

2015-04-15 Thread Some Developer
On 15/04/15 03:37, Curtis Maloney wrote: Was the OP referring to the unique index, or the index created for the LIKE lookups? I was involved in a discussion recently [was there something on list too?] wanting to be able to opt-out of the second index because they knew they didn't need it, and

Re: Why deprecate the ability to reverse using the Python path?

2015-04-15 Thread guettli
Thank you Graham. I will talk with my team mates again. Moving to URLs with names is no good solution for us. But maybe using the view methods itself. Since a lazy reverse() exists since some releases now, removing the whole string magic might be a good idea. Thanks to all django developers

Re: Why deprecate the ability to reverse using the Python path?

2015-04-15 Thread Tim Graham
Please see the ticket and release notes: https://code.djangoproject.com/ticket/22384 https://docs.djangoproject.com/en/1.8/releases/1.8/#passing-a-dotted-path-to-reverse-and-url If you want to continue using dotted paths, you might be able to create a custom url() function that assigns a name

Why deprecate the ability to reverse using the Python path?

2015-04-15 Thread guettli
Today I realized that the ability to reverse using the Python path gets deprecated My source: https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse Imagine you have a very clear directory structure and everyone knows this in your company. The name of an url pattern is redundant. I