Skip to content
This repository has been archived by the owner on Jan 23, 2019. It is now read-only.

Added command add_create_tables for freezing initial SQL #26

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Added command add_create_tables for freezing initial SQL #26

wants to merge 6 commits into from

Conversation

cypreess
Copy link

I have found that arnold has very not useful support for initial tables creation.

In typical approach:
0001_migration) db.create_table(SomeModel)
0002_migration) Add some_column to SomeModel

when you are re-playing migrations on clean database arnold will return Exception in second migration that some_column already exists, because first migration took updated SomeModel and already creates updated SQL table.

To solve this problem I implemented approach similar to Django migrations, I added a tool for creating migrations for CREATE TABLE statement, which is freezing (into strings) SQL that should be run. In this way, after some changes in model, migration will always create a table as seen at that previous time

Usage:

$ arnold add_create_tables fully.qualified.path.SomeModel1 fully.qualified.path.SomeModel2 ...

Outcome of this command is new migration (with incremental number) created with frozen SQL for up and down functions, ready to run.

PS. Order of models given in argument is not important, models will be topologically sorted.

@cypreess
Copy link
Author

Test are fixed now

@cam-stitt
Copy link
Owner

Apologies for the delay on this. I'll work on getting this in over the weekend. Thanks again for the PR.

@cypreess
Copy link
Author

I was also thinking on totally re-invent the way migraitions are handled. We found out that in many situations when several persons are working in feature branches we endup having migrations conflicts.

Alternative approach is just to create migrations with uniq id (name) and each migration should point dependency migrations. Then migrations can be applied in any order that meets dependency requirements. This means that when two feature branches have some migrations, they can be easily put in same directory and migrated (no particular numbering is needed).

New django1.9 migrations is working in similar way

@cam-stitt
Copy link
Owner

I have considered this before. My goal was to ensure that i had the simplest migration API that I could. I'd certainly be open to discussing this in depth as an issue.

@cam-stitt
Copy link
Owner

@cypreess this looks good. I'd love to see a mention of this new utility in docs please. Once that's done, i'll happily merge it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants