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

Database: clear migrations, move data migrations → fixtures #626

Open
pbanaszkiewicz opened this Issue Dec 16, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@pbanaszkiewicz
Member

pbanaszkiewicz commented Dec 16, 2015

We have a number of data migrations that input new values into empty database. Try creating a fresh new database:

$ rm db.sqlite3
$ ./manage.py migrate
$ make superuser
$ make serve

Now log in with admin:admin credentials and go to http://127.0.0.1:8000/workshops/admin/ to see some of the values that we add with migrations.

Since we're switching to fake-generated "fixtures" (see #534 for details), I'd like also to get rid of all migrations that provide initial values for some of the models, and instead use fixtures for that.

I think we can safely use fixtures because these initial values don't change so often.

Also, I think removing all migrations (or squashing them while dropping data migrations) needs to be done carefully. It may require a release solely for this change (so that no new migrations are added).

@pbanaszkiewicz

This comment has been minimized.

Member

pbanaszkiewicz commented Feb 4, 2016

I'm deferring this for now, because with Django 1.9 the migrations are so fast it doesn't matter… It would still be a nice thing, but for now it's just fine.

@pbanaszkiewicz pbanaszkiewicz removed this from the v1.5 milestone Feb 4, 2016

@pbanaszkiewicz pbanaszkiewicz modified the milestone: v1.5.3 Apr 7, 2016

@pbanaszkiewicz pbanaszkiewicz modified the milestones: v1.5.3, v1.5.4 Apr 20, 2016

@pbanaszkiewicz pbanaszkiewicz modified the milestones: v1.6, v1.5.4 May 20, 2016

@pbanaszkiewicz pbanaszkiewicz modified the milestones: v1.6, v1.7 May 29, 2016

@aditnryn

This comment has been minimized.

Member

aditnryn commented Jul 3, 2016

@pbanaszkiewicz I am starting to reconsider this proposal as we progress towards adding PyData specific objects to the database.
Having fixtures would make our tests independent of the initial data we intend to populate our database with.

@pbanaszkiewicz

This comment has been minimized.

Member

pbanaszkiewicz commented Jul 10, 2016

@narayanaditya95 there are advantages to using fixtures, but personally I don't want to touch migrations to fix our previous errors anytime soon.

@chrismedrela

This comment has been minimized.

Collaborator

chrismedrela commented Jul 18, 2016

Side note: squashing migrations doesn't speed up applying them. I've squashed first 87 migrations here (chrismedrela@4e5a29a) and there is no improvement -- applying migrations still takes ~30 seconds on my machine.

@pbanaszkiewicz

This comment has been minimized.

Member

pbanaszkiewicz commented Jul 19, 2016

I don't think we have manpower to do the switch right now, so I'm postponing until I don't know when.

@pbanaszkiewicz pbanaszkiewicz removed this from the v1.7 milestone Jul 19, 2016

@gvwilson

This comment has been minimized.

Member

gvwilson commented Jul 19, 2016

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