feature request: rake task to mark all migrations as ran

[timcharper]

When I run db:reseed, I expect that my data is generated to the current, most up-to-date schema and all of my migrations have been run.

Is it implemented already?

[timcharper]

It seems as if this would do the job:

desc "Mark migrated"
task :mark_all_migrated => [:environment] do
  migration_versions = Dir[Rails.root + "db/migrate/*.rb"].map { |f| File.basename(f).match(/^\d+/)[0] }
  db = Mongoid.master["data_migrations"]
  migration_versions.each do |v|
    if db.find({"version" => v}).count == 0
      db.insert({"version" => v})
      puts "#{v} marked"
    else
      puts "#{v} already marked"
    end
  end
end

[adacosta]

hey tim, thanks for reporting this issue. i'm on my honeymoon at the moment. i'll be able to take a look at it next tue/wed when i get back. i'll keep you updated on my findings.

[timcharper]

Congrats dude! Hope you have a lot of fun :) Hasta pronto

[adacosta]

Hi Tim, sorry I've neglected this ticket. I just peeped the AR source and they don't have anything similar. I'm thinking this feature might be a bit edge-casey and problematic to implement. Any other thoughts?

[timcharper]

I don't think it's edge casey. AR certainly does do it, but not via a rake task like I've shown above.

It does it on schema load... assume_migrated or something like that.

[adacosta]

Ahh, I didn't think to look behind the rake tasks.

With a little more investigation, I see when Migration::Migrator (AR migration.rb) is initialized, it calls Base.connection.initialize_schema_migrations_table (AR schema_statements.rb), which if sm_table (schema migrations) does not exist, calls a block where if si_table (schema info) exists, it uses that version for backwards compatibility. By that I mean it seems an old AR used a schema info table vs. the current schema migrations table and upon processing the schema info table version, current AR drops it. Right before the drop it calls assume_migrated_upto_version (AR schema_statements.rb). The only other place assume_migrated_opto_version is (optionally) called is in Schema self.define (AR schema.rb), which when used takes an arbitrary version number and sets the current version as that number. In AR, "class Schema < Migration" and we're obviously not doing schema/dumps loads, so maybe a rake task is the best place to put this.

[timcharper]

Is the schema related base class specified in ActiveModel then? Would it be best to implement the method there, or just use the rake task as I've provided above? (it has been working well for me)

[adacosta]

It's only used in AR and unfortunately we're lacking schemas. Maybe you could file a feature request with the Mongo db crew for schemas? I'll probably add your code with a slight variation, being the version number is what's passed to it so it acts more like the AR version. In addition, I'll be renaming it to spite you. Thanks Tim.

[timcharper]

Hah, yeah, that would go over well :) Thanks!

[visnup]

I needed this too. I put together a smaller version that also uses VERSION to know what to assume up to:

namespace :db do
  namespace :migrate do
    task :assume => :environment do
      upto = ENV["VERSION"].to_i
      c = Mongoid.master["data_migrations"].tap &:remove
      Dir[Rails.root + "db/migrate/*.rb"].each do |f|
        v = File.basename(f).to_i
        c.insert({ :version => v })
        break if v == upto
      end
    end
  end
end

[adacosta]

I'll look at this in more detail and see what I can do this weekend. I was supposed to follow through with this several months ago. Normal work has been a bit hectic and feature requests are hard; let's go shopping!

[tolsen]

Since MongoDB does not have schemas, this feature is -- in essence -- our db:schema:load . The mongoid model files are in essence a schema.rb. When recreating a db from scratch (e.g. db:reseed), I think it's usually best to just assume we are at the latest migration and not run any. Otherwise your current model files need to be compatible with all past migrations!

Is there any use case for mongoid migrations where one would want to run the migrations on a freshly seeded db? The only case that comes to my mind is where your seeds.rb file is old. But then would an old seed.rb even work with a new model file? It seems the best practice is to keep your seeds.rb file up to date as well and therefore also assume that all migrations are applied.

[adacosta]

Closing because no progress was made on this issue in the last 25 years it was open.