Message from discussion Django, initial data and custom SQL
Received: by 10.100.33.4 with SMTP id g4mr654945ang.25.1234436009841;
Thu, 12 Feb 2009 02:53:29 -0800 (PST)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [220.127.116.11])
by mx.google.com with ESMTP id 7si1032007yxg.12.2009.02.12.02.53.28;
Thu, 12 Feb 2009 02:53:28 -0800 (PST)
Received-SPF: pass (google.com: domain of freakboy3...@gmail.com designates 18.104.22.168 as permitted sender) client-ip=22.214.171.124;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of freakboy3...@gmail.com designates 126.96.36.199 as permitted sender) smtp.mail=freakboy3...@gmail.com; dkim=pass (test mode) header...@gmail.com
Received: by yw-out-2324.google.com with SMTP id 9so338774ywe.15
for <email@example.com>; Thu, 12 Feb 2009 02:53:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
DomainKey-Signature: a=rsa-sha1; c=nofws;
Received: by 10.150.124.2 with SMTP id w2mr855622ybc.213.1234436008723; Thu,
12 Feb 2009 02:53:28 -0800 (PST)
Date: Thu, 12 Feb 2009 19:53:28 +0900
Subject: Re: Django, initial data and custom SQL
From: Russell Keith-Magee <freakboy3...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Feb 12, 2009 at 4:49 PM, Ludvig Ericson
> On Feb 12, 2009, at 07:48, Russell Keith-Magee wrote:
>> On Thu, Feb 12, 2009 at 2:54 PM, Ludvig Ericson
>> <ludvig.eric...@gmail.com> wrote:
>>> I fail to see how "it has consequences for existing code", as Russell
>>> put it.
>> It has consequences because you are proposing to change the order in
>> which indexes and custom SQL are applied. Any code that depends on the
>> existing order will be affected.
> Just want to note that *I'm* not proposing any changes.
So noted :-)
> I don't think it's "the larger point." I misunderstood the triaging
> system, and incorrectly changed it. Bennett reverted. I apologized.
> End of that.
> I realize that my opinions and decisions play a very small role in the
> development of Django, but I try to express them so that core
> developers may read them, and either think "what a retard", or "fair
This is exactly what we want (and need) to happen. We (the core devs)
rely upon community members such as yourself to have these
discussions, taking some of the load off of us so we can concentrate
on having smaller discussions where many of the details have already
been sorted out, making decisions and committing code. In this case,
there was a misunderstanding about the best way to communicate the
result of your discussions, but we've resolved that problem.
> One solution, which is entirely backwards-compatible, would be to say
> that "if you want your custom SQL to run after indices creation, name
> files '*.post.sql,'" or something like that. That has its own issues,
> but you get the general idea.
This was my immediate thought, and yes, it would be backwards
compatible. My immediate counter-reaction is that you would require
several configuration points (post table creation, post index
creation, post data insertion), which means a lot of
difficult-to-explain configuration points.
>> To answer the original question (why is it done in this order) -
>> mostly historical reasons. Originally, Django didn't have fixtures, so
>> initial data were all loaded from initial SQL. It's generally faster
>> to insert data and then add indicies, hence the order. When Django
>> added fixtures, the order wasn't changed.
> I see, so the custom SQL machinery grew out of being a crude version
> of fixtures then.
> I think the cause of confusion here is that Bergstr=F6m and I both were
> expecting it to be for more than loading data -- I want to create a
> view in it (hence my interest), and he wants to drop some excessive
To be clear - I fully acknowledge your use case. There are many
occasions where you need to invoke custom SQL, and the decision to
execute that SQL pre or post index installation is significant. I
would very much like to be able to support this use case - we just
need to find the right way to do it.
> After pondering some more, I realized the docs actually say "initial
> SQL data", and so I'm not sure if this change is actually a good idea
> or not.
There shouldn't be anywhere talking about 'initial SQL data' - I
thought I purged all of those references. If you find any such
references, they should be referring to "custom SQL", or similar
Russ Magee %-)