Loading initial_data

[cgallemore]

Quick question on initial_data for you guys. If I have an app that
I've already ran all previous migrations on, and initial_data was
loaded, but after the fact I needed to add some more data to the
initial_data fixture, should running syncdb --migrate load my new
initial_data fixture? It appears the standard Django syncdb command
loads the initial_data files for each initial_data fixture we have
(every time syncdb is ran), but apps that are managed by South, only
load initial_data if there is a migration that needs to occur, and the
initial_data is loaded after the migration has ran. Is this the
correct behavior, and if so what would be the recommended approach for
updating intial_data if no migration is needed?

Thanks for the help,

-Chad

[Andrew Godwin]

South and initial_data is still something that needs completely
finalising. It probably should re-load initial_data after every migrate,
even if it didn't do anything.

In the meantime, just use the loaddata command on the initial_data if
you want to update it, that's all syncdb/migrate calls.

Andrew

[Rob Madole]

That's basically the work around we came up with (I work with Chad).
Thanks for responding.

Another related thing we ran into is using South to do data
migrations.

We had a 0001_initial and 0002 was referencing data that gets loaded
with an initial_data fixture. In development everything went fine.
When we made it to our staging machine 0002 failed because
initial_data doesn't get loaded until the end of the migration (in our
case I think we had 4 or so to do).

Our workaround was to add a management call_command('loaddata', ...)
to get our fixture in there as the first thing that 0002 forward()
does. Kinda hacky but got us out of the bind.

At first, I was thinking that any 0001 initial migration could just be
followed by a loaddata initial_data for that app. But this won't
work, initial_data may be serialized in a format that is compatible
with migration 0008 or something. In other words, it may not match
the schema right after 0001 runs.

This one seems really tricky. Anyone have any ideas?

Rob

[Andrew Godwin]

My recommended solution is to... not use initial_data! :)

Basically, you should move to calling loaddata (as you did there) from
inside a migration, on a known fixture file (you might want to name them
after the migration). That way, things will always get loaded at the
right point.

If you then want to add things in future, you can add in a new migration
and fixture file (the old one will get overwritten if needed - if you
want to delete things, do it from inside the same migration using the ORM).

Andrew

[Rob Madole]

Oh I like that. Thanks!

[Andrew Godwin]

Glad you do! A "fixturemigration" command might appear in South soon, to
simplify the process of doing this, but I still need to work out the
arguments and what exactly it would do.

Andrew

[Tom Christie]

Is the advice here - ie "don't use initial_data, load fixtures explicitly in migrations instead" still considered the right way to do things?

I ran into some problems using south with initial_data, in that it appears(?) to get loaded twice - once after the initial table creation, and once after all the migrations have been applied.

See this stackoverflow question for the full low down: http://stackoverflow.com/questions/7192675/south-appears-to-be-loading-initial-data-json-twice

Looks like I might just be using South incorrectly, right?

[Roald de Vries]

On Aug 25, 5:20 pm, Tom Christie <christie....@gmail.com> wrote:
> Is the advice here - ie "don't use initial_data, load fixtures explicitly in
> migrations instead" still considered the right way to do things?
>
> I ran into some problems using south with initial_data, in that it
> appears(?) to get loaded twice - once after the initial table creation, and
> once after all the migrations have been applied.
>

> See this stackoverflow question for the full low down:http://stackoverflow.com/questions/7192675/south-appears-to-be-loadin...

>
> Looks like I might just be using South incorrectly, right?

What about using separate settings for testing (ie test_settings.py)
in which 'south' not in INSTALLED_APPS? For me this seems to work just
fine, does it have caveats?

Cheers, Roald

[Andrew Godwin]

Well, it has the caveat that you're then not testing against a
production-like setup - you won't catch any schema errors in the
migrations. If you have other tests to catch that, though, running one
test suite without migrations seems fair.

Andrew