preventing syncdb from loading initial_data
Joseph Kocherhans
I'll want to load an initial_data fixture, but for some existing sites
that I'm upgrading, it's very useful to be able to run syncdb without
loading any fixtures. Thus http://code.djangoproject.com/ticket/6511
I'll write up the docs if this is generally thought of as a good thing
(tm). I imagine Russ might have something else in mind to accomplish
the same thing.
Joseph
Russell Keith-Magee
>
> I ran into a situation today where for every future site I set up,
> I'll want to load an initial_data fixture, but for some existing sites
> that I'm upgrading, it's very useful to be able to run syncdb without
> loading any fixtures. Thus http://code.djangoproject.com/ticket/6511
This sort of thing has been proposed previously. I'm a -0 on adding it.
My reading of 'initial data' is that it should be a minimal set of
data that _must_ exist, and _cannot_ change - default categories, root
nodes of trees, that sort of thing. As a result, my reaction to this
proposal has historically been "if you don't want a fixture to be
loaded every time, it's not initial data - so don't call it that. Call
it something else, and load it when you need it".
I imagine the use case here is that the data in the initial data
fixture might be modified after being loaded, in which case you don't
want the modifications being overwritten on each syncdb. IMHO, the
better solution to this problem would be to ensure that initial_data
for a given model is only loaded for models that have been added as a
result of the syncdb (e.g, on first sync, contrib.User is added, so
the initial_data users are added; on the second sync, blog.Entry is
added, so the initial entry is added, but the initial user is not
reloaded). I haven't looked at this in detail, but my gut reaction is
that this wouldn't be a trivial thing to implement. In the meantime,
calling your fixture something else works fine :-)
Russ %-)
George Vilches
On Jan 29, 2008, at 10:51 PM, Russell Keith-Magee wrote:
>
> On Jan 30, 2008 8:17 AM, Joseph Kocherhans <jkoch...@gmail.com>
> wrote:
>>
>> I ran into a situation today where for every future site I set up,
>> I'll want to load an initial_data fixture, but for some existing
>> sites
>> that I'm upgrading, it's very useful to be able to run syncdb without
>> loading any fixtures. Thus http://code.djangoproject.com/ticket/6511
I'm -0 to the original idea. I would be +1 to the idea if a different
management command was created that did only the creation tasks of
syncdb, but was called something else (create_missing?). syncdb is
named pretty aptly, I think.
But I'm -1 to the below:
> I imagine the use case here is that the data in the initial data
> fixture might be modified after being loaded, in which case you don't
> want the modifications being overwritten on each syncdb. IMHO, the
> better solution to this problem would be to ensure that initial_data
> for a given model is only loaded for models that have been added as a
> result of the syncdb (e.g, on first sync, contrib.User is added, so
> the initial_data users are added; on the second sync, blog.Entry is
> added, so the initial entry is added, but the initial user is not
> reloaded). I haven't looked at this in detail, but my gut reaction is
> that this wouldn't be a trivial thing to implement. In the meantime,
> calling your fixture something else works fine :-)
We rely on the syncdb feature that uses initial_data,json to update
existing rows. As our developers add columns to models and such, we
have to execute ALTER TABLEs by hand when we go from our local
development environment to staging, but then we run syncdb and we get
all the updated fixtures applied to our updated environment. I think
this is not only reasonable but expected behavior, since a broken
fixture due to a DB change *must* be updated before your whole app is
in a working state.
We've already got a great feature in loaddata, let's not waste it. At
most, I would recommend that we add a new management command (which is
awesome easy now, thanks Django devs)! The command would take in a
fixture filename, and then check every app and execute the fixture if
it exists in that app. This is very straightforward, it wouldn't
interfere with existing functionality, and it should pretty painlessly
cover Joseph's original use case needs with maybe only adding a little
bit extra from the base fixtures to the external ones.
Any reason why a combination of the above wouldn't work to cover
everyone's possible use cases, and not break any existing functionality?
gav