New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating plata on an existing database fails #26

Closed
hkage opened this Issue Aug 3, 2012 · 4 comments

Comments

Projects
None yet
4 participants
@hkage
Copy link
Contributor

hkage commented Aug 3, 2012

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

This comment has been minimized.

Copy link
Owner

matthiask commented Aug 23, 2012

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

This comment has been minimized.

Copy link
Owner

matthiask commented Nov 26, 2012

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

This comment has been minimized.

Copy link

armonge commented Nov 26, 2012

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

@andialbrecht

This comment has been minimized.

Copy link
Contributor

andialbrecht commented Nov 27, 2012

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.

@matthiask matthiask closed this in 5fdb9d5 Nov 27, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment