v1.4.0 cleans the 'schema_migrations'

[nepalez]

It seems, in v1.4.0 the cleaner cleans the 'schema_migrations' table as well.

This causes the next db migration to break, because the migration task tries to duplicate old migrations from the very beginning.

[geoffharcourt]

I'm seeing the same behavior in my app in Rails 4.1.

[enthrops]

Confirming on Rails 4.2

[bdarfler]

Confirmed on Postgres/ActiveRecord/Rails 4.1. It seems that the logic now requires the full database.table notation to work properly. A work around would be to add except: %w[public.schema_migrations] but obviously this should be fixed. It also impacts anyone trying to prevent spatial_ref_sys from being truncated.

[uno4ki]

Yeah, nasty bug.
Confirmed on 4.2 with postgres, public.* is a lifesaver

[allavena]

Unrelated to Rails. I can confirm on a Sinatra app with ActiveRecords 4.2

[raphaelcosta]

Same here with Rails 4.2

[felipero]

+1

[lilfaf]

👍

[jonallured]

I recently upgraded to Rails 4.2 and mistakenly thought that had something to do with my schema_migrations table was getting truncated after cucumber runs. I eventually found this issue and I tried the work around of using the except option, but that didn't work.

I ended up downgrading to v1.3.0 for the time being, but I also cloned down the project and ran the tests. Everything is passing and there is a spec for this behavior:

https://github.com/DatabaseCleaner/database_cleaner/blob/master/spec/database_cleaner/active_record/truncation_spec.rb#L36

Any thoughts on how to get a failing test on this? I couldn't help notice that the library runs against activerecord 3.0.0, so that can't be good...

Thanks!
Jon

[jonallured]

I'm new to the internals of this library, so I spent some time reading through things this afternoon and something that stood out to me was the lack of outer loop testing for truncation and the schema_migrations table. What I was looking for was a test that migrates the database, truncates and then asserts about the state of the schema_migrations table, but I couldn't find a test like that. If I've missed something, please let me know!

I took a stab at adding one - both on top of v1.4.0 and off of v1.3.0 in order to ensure that the test was actually proving something. Here are the commits:

• jonallured/database_cleaner@04c263e - passing spec off of v1.3.0
• jonallured/database_cleaner@0a8d1c0 - failing spec off of v1.4.0

The spec isn't great, I'm shelling out to run dropdb and it's probably in the wrong place, but I think this at least illustrates the problem - I hope so, anyway! :)

[dillonwelch]

Confirming on Rails 4.2. Had the issue with v1.4.0, downgraded to v1.3.0 and it went away.

[odigity]

Same here. (Rails 4.2, PostgreSQL 9.3)

Decided to fix it by using except:

DatabaseCleaner.strategy = :truncation, {except: %w[public.schema_migrations]}

Found out the hard way that 'schema_migrations' won't work without prefixing it with 'public.', so thanks for that tip, @bdarfler.

[daqo]

Same for me. Any fix?

[nafaabout]

Same here.

[nafaabout]

@odigity I tried your fix but it does not work.

[nafaabout]

I just downgrade to 1.3.0. and it works.

[odigity]

@nafaabout Here are the exact contents of my lib/tasks/db.rake file:

namespace :db do
  desc 'deletes all data in all tables'
  task empty: :environment do
    DatabaseCleaner.strategy = :truncation, {except: %w[public.schema_migrations]}
    DatabaseCleaner.clean
  end
end

Which runs when I execute rake db:empty.

[jonallured]

Has anyone made any progress on this one? I should have some time this week to work on it, but didn't want to duplicate efforts.

Thanks!
Jon

/cc @etagwerker @bmabey @vrinek @JonRowe

[daqo]

For now, just downgrade to version 1.3.

—
David Qorashi

On Sun, Jan 25, 2015 at 4:36 PM, Jon Allured notifications@github.com
wrote:

Has anyone made any progress on this one? I should have some time this week to work on it, but didn't want to duplicate efforts.
Thanks!
Jon

/cc @etagwerker @bmabey @vrinek @JonRowe

Reply to this email directly or view it on GitHub:
#317 (comment)

[shelling]

confirm on rails 4.1.9

[etagwerker]

While we work on a solution to this, I see two workarounds:

Either

DatabaseCleaner.strategy = :truncation, {except: %w[public.schema_migrations]}

or

Downgrade to 1.3.0

Thanks for your contributions!

[geoffharcourt]

@etagwerker, thanks! Any chance we can get a 1.5.0 release with the fix?

[etagwerker]

Could you check that it's working correctly by using master? If everything is alright I can release 1.4.1 soon.

[geoffharcourt]

Master is able to run specs on Rails 4.2 without messing up the schema_migrations table. Thanks again.

[daqo]

The fix works perfectly.

[mehmetdavut]

@odigity thanks, it works 👍

[joshco]

I just ran into this too. 1.4.1 fixes it

[mib32]

I would like to add, that if you have something like this

DatabaseCleaner.strategy = :truncation, {:except => %w[spatial_ref_sys]}

I mean, have 1.4.1 installed, but configured the exception for some table like spatial_ref_sys then you also would lose your migrations! Just add her, like this.

DatabaseCleaner.strategy = :truncation, {:except => %w[spatial_ref_sys public.schema_migrations]}