Migrating plata on an existing database fails

[hkage]

Hi there,

we recently added plata to our Django application and are using an existing database with South. We added plata to the INSTALLED_APPS list and called manage.py migrate for each application added to the list. We didn't use Django's syncdb command.

INSTALLED_APPS += (
    'plata',
    'plata.shop',
    'plata.contact',
    'plata.discount',
    'plata.payment',
    'plata.product',
)

The initial data script for "plata.shop" (0001_initial) fails, as it refers to "simple.Product" which does not exists:

FATAL ERROR - The following SQL query failed: ALTER TABLE "shop_orderitem" ADD CONSTRAINT "product_id_refs_id_790e3655" FOREIGN KEY ("product_id") REFERENCES "simple_product" ("id") DEFERRABLE INITIALLY DEFERRED;
The error was: relation "simple_product" does not exist

It seems that the initial South migration file uses a non existing app or has an old reference to the plata example app, that isn't part of the source distribution anymore. Therefore we used the following workaround to successfully migrate the whole plata application:

• Delete the plata.shop migration directory
• Call manage.py syncdb
• Copy the plata.shop migration directory back to the original path
• Call migrate --fake shop

Maybe you could modify the initial migration file, so that migrating Plata on an existing database without syncdb works.

Thanks in advance, Henning

[matthiask]

Hi Henning

That's a known problem, and I'm not sure how this should be solved. We're emulating a lazy foreign key with the PLATA_SHOP_PRODUCT setting, something which isn't really supported by Django (and therefore not supported by South either).

I'm using the simple example to create the migrations, unfortunately this means that products in all other apps will lead to the errors you're seeing.

I'm a bit stumped how we can provide migrations in Plata itself and still support PLATA_SHOP_PRODUCT.

Your fix is certainly correct but involves handiwork, something which I'd like to avoid if possible at all.

Thanks, Matthias

[matthiask]

So maybe including migrations wasn't such a good idea after all.

I'm thinking that the best way forward might be to remove the migrations, and provide instructions in the release notes how migrations could be generated if necessary.

Opinions?

[armonge]

I for one vouch for not having migrations, just because "simpler is better"

[andialbrecht]

One argument against migrations would be that the final Product model is configurable and hence not suitable for migrations. So I'd prefer some kind of documentation that explains how to activate (and maintain) migrations for a distinct Plata installation.