rake db:reset propagates migrations

[ain]

Weird problem, whenever I ran rake db:reset all the tables are nicely emptied except for the seed_migration_data_migrations which effectively displays all data migrations, it's not empty.

Truncating it manually and running db:reset again fills it up every time, but no seed migration actually happens.

Ideas?

[ain]

Just tried with the latest 1.0.5 as well and unfortunately did not have much luck.

[pjambet]

Hey, thanks for reporting this, I'll try to look into it next week.

Which DB are you using? MySQL? and which version?

[ain]

Reproduced on my other Mac with following specs:

rails (3.2.20)
mysql2 (0.3.16)
Server version: 5.6.20 MySQL Community Server (GPL)

[ain]

The original machine where I tackled it first is running:

rails (3.2.20)  
mysql2 (0.3.16)
Server version: 5.1.44 Source distribution

[ain]

And reproduced on server as well:

Server version: 5.1.73-1 (Debian)

[ain]

I've created a temporary rake task to be used instead of the standard rake db:reset, see the Gist

[pjambet]

Thanks for all the details, I'll let you know as soon as I have time to work on this issue.

Thanks!

[ain]

No probs, I'm just pushing it all here for the reference before I forget.

I'll take a look myself too and if there's some more time, I'll push a PR for you :)

[pjambet]

Sorry for not looking at this earlier, I'm trying to do some cleanups with all the open issues. Is this still an issue?

[ain]

Hey, I'll have to try. I'm running a specific task to reset it cleanly. Will disable and try the original way.

Stay tuned.

[ain]

Just tried the most recent 1.1.0 and the issue persists, we need a fix.

[pjambet]

After re-reading the original issue, I'm wondering if this is actually a bug or "expected" behavior.

rake db:reset runs runs db:drop db:setup under the hood, and db:setup runs db:schema:load, db:seed

Running db:seed will execute db/seeds.rb, if this file has been generated by this gem, i'll contain a call to SeedMigration::Migrator.bootstrap(20151008212937) where the argument to bootstrap is the timestamp of the last seed migration ran.

bootstrap will mark all the migrations older than this timestamp as previously ran by inserting them in the seed_migration_data_migrations table. This is why this table is not empty after a db:reset.

This is useful when you generate a new seed migration after a db:reset and you run rake seed:migrate, we only want the new migration to be run, not the old ones.

This is similar to what rake db:schema:load does, it doesn't re run all the schema migrations, it executes the content of schema.rb and then marks all the schema migrations older than the timestamp in ActiveRecord::Schema.define(version: timestamp) as ran by inserting them in the schema_migrations table.

The assumption we're making here is that your seed migrations should affect models that you register in seed migrations, so when you run rake seed:migrate, you're getting a new seeds.rb file that should be enough to bootstrap a new environment, without having to re run all the previous seed migrations.

So it seems to me like this is expected behavior, in that case, we should maybe edit the README to make this more explicit.

Let me know if you have any questions or if anything isn't really clear.

PS: Thanks again for taking the time to look into this old issue, and for your other contribution to this gem :)

[ain]

Good point.

About my use-case: I'm using it to automate data population, so time-to-time, esp. prior going live, the database is wiped clean with initial data seeded in, sometimes tens of millions of records. Sort of full reset. What about some --hard option and/or YAML config?

[pjambet]

I'm not against adding new features to the gem to support new use cases, but first I want to make sure I clearly understand your situation.

If all the models that store the data that you need to seed for the new environment are registered in the initializer, then every time your run a seed migration your seeds.rb should contain all the data you need.

Are you not registering certain models because the seeds file would become to big if we're talking about millions of records? or are there other considerations?

[pjambet]

Following your suggestion of using something like --hard, what about something like this:

Run all the seed migrations even if they were run before:

rake seed:migrate FORCE=true 

Run a specific migration even if was run before:

rake seed:migrate MIGRATION=20140407162007_add_foo.rb FORCE=true

Rake doesn't make it easy to use command line args like --arg, so using ENV arguments like this seems like the easiest option, and we're already using this pattern to run specific migrations.

[ain]

@pjambet I'd change this issue from bug to enhancement for the reasons listed above.

[pjambet]

Indeed, just updated this.