Django, initial data and custom SQL - Django developers

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Django, initial data and custom SQL
Received-SPF: pass (google.com: domain of freakboy3...@gmail.com designates 74.125.46.29 as permitted sender) client-ip=74.125.46.29;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=stAGYnVTXM9H5nsaluAEzrJ3DOsD49j0Z0Cs7PHLfV2F8rDLbjSd1BdZHCwdzHoo9b
         OnSvLOeOif02FVH2CuytiZmHPwkgjWjfYs0DDmvxWQKpRmR334Ltv4mnXPQDSVOkViKd
         iSj12WDsiBAHO7zA+OeFVdwxba4zV+GwZZO3I=
MIME-Version: 1.0
In-Reply-To: <AEC24ED0-5D18-4283-A763-C8FC4A8D65EB@gmail.com>
References: <58b8a820-6da4-4653-962e-ecf0693de2c0@g38g2000yqd.googlegroups.com>
	 <b44d6ae4-ecb2-4014-9444-df87a88e0225@u13g2000yqg.googlegroups.com>
	 <9ee6aedf-49d1-4a0d-94f7-1cda1812a...@x10g2000yqk.googlegroups.com>
	 <31bed974-6c76-4628-8a7a-f606074d6...@j38g2000yqa.googlegroups.com>
	 <1070A308-2668-4A60-A492-076791D0B...@gmail.com>
	 <720ff77c0902112248mbf40e3p7f5ec3c6dc3ce...@mail.gmail.com>
	 <AEC24ED0-5D18-4283-A763-C8FC4A8D6...@gmail.com>
Date: Thu, 12 Feb 2009 19:53:28 +0900
Message-ID: <720ff77c0902120253i60c5dbe1w139cb34042d28...@mail.gmail.com>
Subject: Re: Django, initial data and custom SQL
From: Russell Keith-Magee <freakboy3...@gmail.com>
To: django-developers@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 12, 2009 at 4:49 PM, Ludvig Ericson
<ludvig.eric...@gmail.com> wrote:
>
> 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.

No problems.

> 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
> point."

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.

Correct.

> 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
> indices.

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
phrasing.

Yours,
Russ Magee %-)
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
