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

I agree this is a bug, and I think it's independent of the discussion of customisable indexes. Postgres creates the necessary index for unique constraints automatically as Tommy said. I'm guessing other backends do too, because the explicit index creation DDL is omitted when unique is True in t

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

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 it was _huge_ on their database. -- C On 1

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

I believe that Postgres will *always* create an index on a column with a UNIQUE constraint. regression=> create table yo (id serial primary key, blah varchar(32) unique); CREATE TABLE regression=> \d yo Table "public.yo" Column | Type | Modifiers -

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

Using Django 1.8, psycopg2 2.6 and PostgreSQL 9.4.1. I have a model with a models.TextField(unique=True, db_index=False, primary_key=False) field in it. I understand that an index is created because of the comment shown in this code: https://github.com/django/django/blob/master/django/db/ba

Re: Newer version of Sqlite (3.8.9) breaks django -- should we backport

For reference, Tim just backported your patch to 1.7 and 1.8 . /Markus On Tuesday, April 14, 2015 at 5:25:28 PM UTC+2, Peter J.

Newer version of Sqlite (3.8.9) breaks django -- should we backport

Official ticket: https://code.djangoproject.com/ticket/24637 PR: https://github.com/django/django/pull/4494 Sqlite 3.8.9 which was just released on 4/8/2015 as gold has changed behavior with index_list() functionality by adding 2 more columns of data the returned queryset. This breaks introspe

Re: Django Admin New Look

> On 07 Apr 2015, at 18:15, Aymeric Augustin > wrote: > > 2015-04-07 17:25 GMT+02:00 Marc Tamlyn : > The primary questions to establish answers to before a possible merge in my > opinion are: > - Do we ship both, or just the new one and release the old one as a third > party package? > > I'd

Re: Removing global database converters and adapters for datetimes

I think this is likely a good plan. There are a number of other places where we globally register converters/adapters (at least in postgres land) rather than explicitly registering them on each connection. I'm not sure if they're an issue in the same way though. Marc On 13 April 2015 at 20:11, Ca