Giter Site home page Giter Site logo

data-migrate's Introduction

Data Migrate

  • Version
  • License
  • .github/workflows/build.yml
  • Reviewed by Hound

Run data migrations alongside schema migrations.

Data migrations are stored in db/data. They act like schema migrations, except they should be reserved for data migrations. For instance, if you realize you need to titleize all your titles, this is the place to do it.

directory tree example

Why should I use this?

With data-migrate you can generate your migrations for data as you would schema in your regular work flow.

For setting tasks that don't require any intermediate AR activity, like dev and test, you stick with db:migrate. For production and QA, you change their scripts to db:migrate:with_data. Of course you want to test your migration, so you have the choice of db:migrate:with_data or data:migrate to just capture that data change.

What does it do?

Data migrations are stored in db/data. They act like schema migrations, except they should be reserved for data migrations. For instance, if you realize you need to titleize all yours titles, this is the place to do it. Running any of the provided rake tasks also creates a data schema table to mirror the usual schema migrations table to track all migrations.

Rails Support

Support Rails 6.1 through 7.1

v1

If you've installed previous to v1.1.0, you'll want to delete the create_data_migrations_table migration.

Installation

Add the gem to your project

# Gemfile
gem 'data_migrate'

Then bundle install and you are ready to go.

So you know, when you use one of the provide rake tasks, a table called data_migrations will be created in your database. This is to mirror the way the standard db rake tasks work.

Usage

Generating Migrations

You can generate a data migration as you would a schema migration:

rails g data_migration add_this_to_that

Rake Tasks

$> rake -T data
rake data:abort_if_pending_migrations          # Raises an error if there are pending data migrations
rake data:dump                                 # Create a db/data_schema.rb file that stores the current data version
rake data:forward                              # Pushes the schema to the next version (specify steps w/ STEP=n)
rake data:migrate                              # Migrate data migrations (options: VERSION=x, VERBOSE=false)
rake data:migrate:down                         # Runs the "down" for a given migration VERSION
rake data:migrate:redo                         # Rollbacks the database one migration and re migrate up (options: STEP=x, VERSION=x)
rake data:migrate:status                       # Display status of data migrations
rake data:migrate:up                           # Runs the "up" for a given migration VERSION
rake data:rollback                             # Rolls the schema back to the previous version (specify steps w/ STEP=n)
rake data:schema:load                          # Load data_schema.rb file into the database without running the data migrations
rake data:version                              # Retrieves the current schema version number for data migrations
rake db:abort_if_pending_migrations:with_data  # Raises an error if there are pending migrations or data migrations
rake db:forward:with_data                      # Pushes the schema to the next version (specify steps w/ STEP=n)
rake db:migrate:down:with_data                 # Runs the "down" for a given migration VERSION
rake db:migrate:redo:with_data                 # Rollbacks the database one migration and re migrate up (options: STEP=x, VERSION=x)
rake db:migrate:status:with_data               # Display status of data and schema migrations
rake db:migrate:up:with_data                   # Runs the "up" for a given migration VERSION
rake db:migrate:with_data                      # Migrate the database data and schema (options: VERSION=x, VERBOSE=false)
rake db:rollback:with_data                     # Rolls the schema back to the previous version (specify steps w/ STEP=n)
rake db:schema:load:with_data                  # Load both schema.rb and data_schema.rb file into the database
rake db:structure:load:with_data               # Load both structure.sql and data_schema.rb file into the database
rake db:version:with_data                      # Retrieves the current schema version numbers for data and schema migrations

Tasks work as they would with the 'vanilla' db version. The 'with_data' addition to the 'db' tasks will run the task in the context of both the data and schema migrations. That is, rake db:rollback:with_data will check to see if it was a schema or data migration invoked last, and do that. Tasks invoked in that space also have an additional line of output, indicating if the action is performed on data or schema.

With 'up' and 'down', you can specify the option 'BOTH', which defaults to false. Using true, will migrate both the data and schema (in the desired direction) if they both match the version provided. Again, going up, schema is given precedence. Down its data.

When using rake db:migrate:with_data migrations will be run in ascending order by their version. For example, if you have a data migration with version 20230410000000 and a schema migration with version 20230415000000, expect the data migration to run first.

rake db:migrate:status:with_data provides an additional column to indicate which type of migration.

Configuration

data_migrate respects ActiveRecord::Base.dump_schema_after_migration. If it is set to false, data schema file will not be generated

By default, data migrations are added to the db/data/ path. You can override this setting in config/initializers/data_migrate.rb

DataMigrate.configure do |config|
  config.data_migrations_path = 'db/awesomepath/'
  config.data_template_path = Rails.root.join("lib", "awesomepath", "custom_data_migration.rb")
  config.db_configuration = {
    'host' => '127.0.0.1',
    'database' => 'awesome_database',
    'adapter' => 'mysql2',
    'username' => 'root',
    'password' => nil,
  }
  config.spec_name = 'primary'
end

Capistrano Support

The gem comes with a capistrano task that can be used instead of capistrano/rails/migrations.

Just add this line to your Capfile:

require 'capistrano/data_migrate'

From now on capistrano will run rake db:migrate:with_data in every deploy.

Rails Engines support

This gem also has a initial support for adding data migrations inside Rails engines. Inside the Engine's class initializer (the one that inherits from Rails::Engine, usually inside engines/ENGINE_NAME/lib/engine.rb) you need to add something like this:

module EngineName
  class Engine < ::Rails::Engine
    initializer :engine_name do |app|
      ::DataMigrate.configure do |data_migrate|
        default_path = ::DataMigrate::Config.new.data_migrations_path
        data_migrate.data_migrations_path = [default_path, root.join('db', 'data')]
      end
    end
  end
end

Then, in the Engine's db/data folder, you can add data migrations and run them as usual.

Contributing

Testing

Run tests for a specific version of Rails

bundle exec appraisal install
bundle exec appraisal rails-6.1 rspec
bundle exec appraisal rails-7.0 rspec
bundle exec appraisal rails-7.1 rspec

Thanks

Andrew J Vargo Andrew was the original creator and maintainer of this project!

Jeremy Durham for fleshing out the idea and providing guidance.

You! Yes, you. Thanks for checking it out.

data-migrate's People

Contributors

anniejl avatar antronin avatar artofhuman avatar bazay avatar berniechiu avatar borama avatar chaunce avatar craineum avatar daztmb avatar defsprite avatar dependabot[bot] avatar enomadebby avatar gdott9 avatar ilyakatz avatar jturkel avatar lewhit avatar ngan avatar pierre-michard avatar rbarrera87 avatar reidab avatar salbertson avatar slavakisel avatar tatsuyafw avatar technicalpickles avatar timkrins avatar tobyndockerill avatar tvdeyen avatar vagishvela avatar wildmaples avatar y-yagi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

data-migrate's Issues

rails db:setup doesn't mark data migrations completed using data_schema.rb

I've been running into an issue with rails db:setup command not loading the data_schema.rb file, like it does for schema.rb. Basically, when dropping my development database and setting it up again, rails data:migrate:status shows all previous migrations as incomplete, even though the data_schema.rb file contains the last version number.

I also tried running the tasks by unpacking setup: db:create, and db:schema:load:with_data in order, with no change.

I've gone through the code a bit, and noticed that the data:schema:load:with_data task runs DataMigrate::DatabaseTasks.load_schema_current, which is an ActiveRecord method. However, this method internally uses another method schema_file(format) for determining the file which should be used to load the version.

However, DataMigrate::DatabaseTasks only defined a self.data_schema_file() method which, as far as I can tell, is never used except for dumping the version after a data migration is executed. Shouldn't this class override ActiveRecord's schema_file(format) method instead of defining a new method?

I tried a simple method rename to override the original implementation, but that didn't have any effect. Do you have any idea what could be going wrong?

Test coverage?

I don't believe this gem has any test coverage as of now, but it might be useful especially as we ensure it works with Rails 5 #39 and also so that nothing breaks as the gem is kept in working order. Especially since we are dealing with data here.

Its pretty cool this has been around for so many years, and I think it is a cool gem.

@ilyakatz If that seems ok to you I was wondering what testing suite we should use? I've had some brief experience with rspec and could help write the tests.

Add capistrano task for migrating data

I have added a cap task in one of my projects for performing data migrations in the deployment pipeline.

@ilyakatz Do you think this can me merged in the gem ? I think that the task should be required in the Capfile only.

The rake task is practically identically to capistrano/rails deploy:migrate task.

namespace :deploy do

  desc 'Runs rake data:migrate if migrations are set'
  task :data_migrate => [:set_rails_env] do
    on fetch(:migration_servers) do
      conditionally_migrate = fetch(:conditionally_migrate)
      info '[deploy:data_migrate] Checking changes in /db/data' if conditionally_migrate

      if conditionally_migrate && test("diff -q #{release_path}/db/data #{current_path}/db/data")
        info '[deploy:data_migrate] Skip `deploy:data_migrate` (nothing changed in db/data)'
      else
        info '[deploy:data_migrate] Run `rake data:migrate`'
        invoke :'deploy:data_migrating'
      end
    end
  end

  desc 'Runs rake data:migrate'
  task data_migrating: [:set_rails_env] do
    on fetch(:migration_servers) do
      within release_path do
        with rails_env: fetch(:rails_env) do
          execute :rake, 'data:migrate'
        end
      end
    end
  end

  after 'deploy:migrate', 'deploy:data_migrate'
end

namespace :load do
  task :defaults do
    set :conditionally_migrate, fetch(:conditionally_migrate, false)
    set :migration_role, fetch(:migration_role, :db)
    set :migration_servers, -> { primary(fetch(:migration_role)) }
  end
end

If you think this is appropriate I can submit a PR shortly.

Thanks!

problem with ActiveRecord 4.1.1

Hey

I bumped rails version from 4.0.2 to 4.1.1 and started receiving the following error while running migrate:with_data task:

NoMethodError: undefined method `group_by' for "db/data":String

ruby/2.1.0/gems/activerecord-4.1.1/lib/active_record/migration.rb:1010:in validate' ruby/2.1.0/gems/activerecord-4.1.1/lib/active_record/migration.rb:917:ininitialize'
ruby/2.1.0/gems/data_migrate-1.2.0/tasks/databases.rake:315:in new' ruby/2.1.0/gems/data_migrate-1.2.0/tasks/databases.rake:315:inpending_data_migrations'
ruby/2.1.0/gems/data_migrate-1.2.0/tasks/databases.rake:311:in pending_migrations' ruby/2.1.0/gems/data_migrate-1.2.0/tasks/databases.rake:12:inblock (3 levels) in <top (required)>'
Tasks: TOP => db:migrate:with_data

Thanks

Does this gem affect the extensions listed in schema.rb?

Hi! I noticed after running some migrations locally that my schema.rb file had a few extensions removed, and since the branch I'm working on has nothing new other than this gem and some schema migrations, I'm wondering if this gem does anything specific with the db:migrate task or similar that could have caused this change?

These lines were removed from my schema.rb:

# These are extensions that must be enabled in order to support this database	
enable_extension "pg_stat_statements"	
enable_extension "plpgsql"

I'm still new to the Ruby/Rails world, so don't know enough yet how much of an impact this will have on my app, but I wanted to reach out and try to understand why this is happening. Thanks!

data:rollback fails depending on order of data and schema migrations

I run into the following issue:
When the order of data and schema migrations (based on filename) is intermixed, I cannot do a data:rollback if there are schema migrations in between the current and previous data migration.

Consider the following output of db:migrate:status:with_data

Status    Type    Migration ID   Migration Name
------------------------------------------------------------
  up     schema  20160517153654  Create links
  up     schema  20160517153831  Create assets
  up     schema  20161202212757  Devise create users
  up      data   20169423231126  Add users
  up      data   20169517225124  Add basic data
  up     schema  20171108210818  Create factions
  up     schema  20171116173510  Create entries
  up      data   20180517231700  Add draw events

At this point, I can do a data:rollback to revert the latest data migration. However, any further calls to data:rollback will silently fail. The overall behavior and log messages are as described in #67 .

I would expect that data:rollback would not be affected by schema migration at all. Is this normal?

Extend to have more migration paths + rake task

We are successfully using rake data:migrate after our deploys to do non-critical data migrations after the deploy has successfully completed; however, we are realizing that are some data migrations that really should be run a little bit closer to when the schema migration (db/migrate) was run. Ideally what we'd like is to have a db/data1 and db/data2 folders (obviously with better names more descriptive of what they did) that each came with their own rake task like rake data:migrate1 and rake data:migrate2 (also ideally with better names 😄 ) so that our deploy had better control of when they were run. I was a bit excited on seeing this issue here but that appears to be a different request... the only solution I can see that achieves what we want here is to fork the gem, change the migrations_path to db/data2, and change the rake task to something like namespace :<our custom data migration rake task name> do...task...
This might get the job done but doesn't seem so elegant. Any ideas on how to get what we want here?

Rails compatibility

Was there an issue that you found with Rails versions above 3.0.7? I'm trying to update to 3.0.11 but data-migrate is keeping that from happening

db:schema:load:with_data no longer loading with data migrations

We're upgrading to Rails 5.2 and needed the latest release of data_migrate. Unfortunately, this has totally broken deployment because db:schema:load:with_data no longer works.

On 3.3.0, rake db:schema:load:with_data would run db:schema:load and then insert all of the currently run data migrations.

On 4.0.0, rake db:schema:load:with_data, it doesn't run the data load process, and it says the loaded version is s0.

rake db:schema:load > schema_load.txt

rake db:schema:load > schema_load_with_data.txt

> ls schema_load*
-rw-r--r--  1 bbugh  staff  5456 Jun  4 13:21 schema_load.txt
-rw-r--r--  1 bbugh  staff  5456 Jun  4 13:21 schema_load_with_data.txt

If I switch my Gemfile to force 3.3.0, the command works as expected. If I switch to 4.0.0, it breaks. Unfortunately. 3.3.0 breaks on everything else since it's not Rails 5.2 compatible.

Is there an easy workaround for this?

Should `data_schema.rb` be committed to repository?

What's the general advice on data_schema.rb should it be committed to repository or ignored?

The reason I ask is because this file is generated after running db:migrate:with_data and I am unsure what happens if I commit it, deploy my application and then execute the rake task in production, does it think the data migration was already run, does it compare the .rb file with the version in the database, how does it work?

Thank you kindly

Rails 4.1.9

Hello,

We're trying to upgrade our application to latest Rails version of the 4.1 series and it appears running data migrations is now storing in the wrong table. (i.e. in 'schema_migrations' and not 'data_migrations'). Is there a fix our there or is this a known problem?

Any help would be great.

Thanks!

data:rollback doesn't execute anything

rake data:rollback used to work for me. After adding some recent data migrations, when I execute rake data:rollback, I get the following output with no execution of the down function:

DataMigrate::DataSchemaMigration Load (2.9ms) SELECT "data_migrations".* FROM "data_migrations"
ActiveRecord::SchemaMigration Load (2.2ms) SELECT "schema_migrations".* FROM "schema_migrations"

I tried to identify which one of the 15-20 latest data migrations broke it, but I just can't figure it out. Sometimes it stops running after adding a certain data migration script, but if I drop the database, re-create the schema and reload all the data migrations, that script works (meaning that I can do a rollback on it). I looked at the source code and I noticed it is based on the ActiveRecord migrations rollback functionality. Even so, whatever I did, I still can't figure out why it's not firing the rollback. rake data:migrate and rake db:migrate and rake db:rollback all work just fine (for the new scripts).

Gem Load Error: Directly inheriting from ActiveRecord::Migration is not supported

Just tried to include the data_migrate gem in my application, but when I try to generate a data migration, I get this error:

Traceback (most recent call last):
	18: from bin/rails:4:in '<main>'
	17: from bin/rails:4:in 'require'
	16: from /Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/commands.rb:16:in '<top (required)>'
	15: from /Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/command.rb:44:in 'invoke'
	14: from /Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/command/base.rb:63:in 'perform'
	13: from /Users/matthew/.gem/ruby/2.5.0/gems/thor-0.20.0/lib/thor.rb:387:in 'dispatch'
	12: from /Users/matthew/.gem/ruby/2.5.0/gems/thor-0.20.0/lib/thor/invocation.rb:126:in 'invoke_command'
	11: from /Users/matthew/.gem/ruby/2.5.0/gems/thor-0.20.0/lib/thor/command.rb:27:in 'run'
	10: from /Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/commands/generate/generate_command.rb:19:in 'perform'
	 9: from /Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/command/actions.rb:15:in 'require_application_and_environment!'
	 8: from /Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/command/actions.rb:15:in 'require'
	 7: from /Users/matthew/work/bible_reading/config/application.rb:7:in '<top (required)>'
	 6: from /Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler.rb:114:in 'require'
	 5: from /Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:65:in 'require'
	 4: from /Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:65:in 'each'
	 3: from /Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:76:in 'block in require'
	 2: from /Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:76:in 'each'
	 1: from /Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:80:in 'block (2 levels) in require'
/Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:84:in 'rescue in block (2 levels) in require': There was an error while trying to load the gem 'data_migrate'. (Bundler::GemRequireError)
Gem Load Error is: Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for:

  class DataMigrate::Migration < ActiveRecord::Migration[4.2]
Backtrace for gem load error is:
/Users/matthew/.gem/ruby/2.5.0/gems/activerecord-5.1.4/lib/active_record/migration.rb:525:in 'inherited'
/Users/matthew/.gem/ruby/2.5.0/gems/data_migrate-3.0.1/lib/data_migrate/migration.rb:2:in '<module:DataMigrate>'
/Users/matthew/.gem/ruby/2.5.0/gems/data_migrate-3.0.1/lib/data_migrate/migration.rb:1:in '<top (required)>'
/Users/matthew/.gem/ruby/2.5.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:292:in 'require'
/Users/matthew/.gem/ruby/2.5.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:292:in 'block in require'
/Users/matthew/.gem/ruby/2.5.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:258:in 'load_dependency'
/Users/matthew/.gem/ruby/2.5.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:292:in 'require'
/Users/matthew/.gem/ruby/2.5.0/gems/data_migrate-3.0.1/lib/data_migrate.rb:3:in '<top (required)>'
/Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:81:in 'require'
/Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:81:in 'block (2 levels) in require'
/Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:76:in 'each'
/Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:76:in 'block in require'
/Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:65:in 'each'
/Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:65:in 'require'
/Users/matthew/.gem/ruby/2.5.0/gems/bundler-1.16.1/lib/bundler.rb:114:in 'require'
/Users/matthew/work/bible_reading/config/application.rb:7:in '<top (required)>'
/Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/command/actions.rb:15:in 'require'
/Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/command/actions.rb:15:in 'require_application_and_environment!'
/Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/commands/generate/generate_command.rb:19:in 'perform'
/Users/matthew/.gem/ruby/2.5.0/gems/thor-0.20.0/lib/thor/command.rb:27:in 'run'
/Users/matthew/.gem/ruby/2.5.0/gems/thor-0.20.0/lib/thor/invocation.rb:126:in 'invoke_command'
/Users/matthew/.gem/ruby/2.5.0/gems/thor-0.20.0/lib/thor.rb:387:in 'dispatch'
/Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/command/base.rb:63:in 'perform'
/Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/command.rb:44:in 'invoke'
/Users/matthew/.gem/ruby/2.5.0/gems/railties-5.1.4/lib/rails/commands.rb:16:in '<top (required)>'
bin/rails:4:in 'require'
bin/rails:4:in '<main>'
Bundler Error Backtrace:

Add data migrations to pending migrations check?

Would it be possible to

a. either add a separate configuration variable from the config.active_record.migration_error setting like

  config.active_record.data_migration_error = :page_load

so that if there is a data migration yet to be run in db/data it throws a pending migration error on page load or ...

b. have db/data be checked as part of the default Rails pending migration check (which would automatically throw an error if there were pending migrations in either db/data or db/migrate)

LoadError: cannot load such file -- pry

Stack trace:

LoadError: cannot load such file -- pry
/home/deploy/apps/app/shared/bundle/ruby/2.3.0/gems/activesupport-4.2.10/lib/active_support/dependencies.rb:274:in `require'
/home/deploy/apps/app/shared/bundle/ruby/2.3.0/gems/activesupport-4.2.10/lib/active_support/dependencies.rb:274:in `block in require'
/home/deploy/apps/app/shared/bundle/ruby/2.3.0/gems/activesupport-4.2.10/lib/active_support/dependencies.rb:240:in `load_dependency'
/home/deploy/apps/app/shared/bundle/ruby/2.3.0/gems/activesupport-4.2.10/lib/active_support/dependencies.rb:274:in `require'
/home/deploy/apps/app/shared/bundle/ruby/2.3.0/gems/data_migrate-5.0.0/tasks/databases.rake:2:in `<top (required)>'

Affecting version 5.0.0 but rolling back to ~> 4.0.0 resolves the issue

Extend data migrations path

Hi, folks, you check pending migrations specifying 'db/data' for it, it means Migrator will search only for this folder. Rails has ability to extend migrate path using config.paths['db/migrate'] << 'path to your migration'. Could you add a similar variable to your project?

Data migration failing with missing attributes

Hi,

We tried using this gem for our application which is already developed long way and in production. We have many models and wanted to populated these tables with some data in QA.

Am getting below missing attribute error. Is this gem tested against 3.2 version? I see people saying it is working fine for them. Just checking if something messed up on my end.

unknown attribute: xxxxxx
../vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.12/lib/active_record/attribute_assignment.rb:88:in block in assign_attributes' ../vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.12/lib/active_record/attribute_assignment.rb:78:ineach'
../vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.12/lib/active_record/attribute_assignment.rb:78:in assign_attributes' ../vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.12/lib/active_record/base.rb:497:ininitialize'

-- Thanks

Data Migration version

Is it correct to using ActiveRecord::Migrator.current_version to get current data_migration version?

current_data_version = ActiveRecord::Migrator.current_version

As far as I understand, you need to use DataMigrate::DataMigrator.current_version here, right?

Schema is edited, but there is no data migration.

Hi all,

I noticed that the data_migrations table gets auto-created and added to the schema.rb when a data migration is ran.

when you use one of the provide rake tasks, a table called data_migrations will be created in your database

But without an actual ActiveRecord::Migration to create this table the lines that define data_migrations get removed from schema.rb when other developers run rake db:migrate without having any data migrations present.

Was there a reason to not require an explicit ActiveRecord::Migration to create this table?

Can't find capistrano deploy:migrate task after require 'capistrano/data_migrate'

First try to deploy with data_migrations today, installing gem version data_migrate: 5.3.2, capistrano: 3.11.0,
Capfile:

...
# require 'capistrano/rails/migrations'
require 'capistrano/data_migrate'
...

got backtrace on bundle exec cap staging T & cap staging deploy:check :

(Backtrace restricted to imported tasks)
cap aborted!
Don't know how to build task 'deploy:migrate' (See the list of available tasks with rake --tasks)
Did you mean? deploy:starting

Long running data migrations happen within a transaction

I have a data migrate that needs to update 12000 rows in a table. The problem is that data-migrations happen within a transaction and that transaction is way too big. Is there a way we can disable running the data migrate within a transaction?

data_migrations table not populated via db:schema:load

When starting an app with a blank database, the data_migrations table is not configured with the already-run data migrations. This is a known issue, but it seems as though a concrete use-case hasn't been mentioned before.

In the README there's a nice example of why this gem is useful. If I'm not mistaken, with this gem the workflow would look something like:

  1. generate a schema migration to add a comment column to Post
  2. generate a data migration to move the contents of the first comments to the Post
  3. generate a schema migration to drop the column_id column from Post
  4. generate a schema migration to drop the comments table

When running rake db:migrate:with_data the migrations would be combined and sorted, running them in the correct order and writing the timestamps to their respective *_migrations tables.

The problem comes when deploying the app to a new database. When running rake db:schema:load the migrations with timestamps before or equal to the timestamp version in schema.rb are inserted into the schema_migrations table (https://github.com/rails/rails/blob/4-2-stable/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L839 called from https://github.com/rails/rails/blob/4-2-stable/activerecord/lib/active_record/schema.rb#L45). After loading the schema, the schema_migrations table would have entries for migration numbers 1, 3, and 4, with the version number in schema.rb being the timestamp for migration 4. These migrations are then prevented from being unnecessarily re-run when rake db:migrate is run.

There is no data migrations equivalent.

This means that running rake db:migrate:with_data after the schema is loaded will cause the data migration (migration 2 above) to be executed, because there is no corresponding entry in the data_migrations table. This will raise an exception because the comments table does not exist anymore.

@cheerfulstoic initially raised the issue (#2) and @edk proposed a fix (#20).

There is a small edge-case with @edk's solution and that is it always assumes that a schema migration is always the last migration. If a data migration comes last, it would be re-run.

A solution that fixes this edge case would be for gem to create its own schema file where it would keep track of the current version.

# db/data_schema.rb

ActiveRecord::Schema.define(version: 20170807000000) do; end

Then, attempting to keep as many similarities to the way Rails does it, we would update this version every time a data migration is successfully completed and use it to determine which data migrations have already been completed.

Are there any misconceptions I've made about the gem's behaviour?
Is this proposed solution the best one?

I'm happy to discuss here and submit a PR if we're agreed that this is an issue that should be fixed.

Data Migration with Postgres, logging version to wrong table

Hi,

I just setup Data Migrate with Rails 4 and Postgres 9.2, and am having an issue with the version being stored in the wrong table. Even though: 1) I use the '--skip-schema-migration' flag, and 2) create a migration (only) in the db/data folder, when I run 'rake data:migrate', the version is stored in the schema_migrations table, and not data_migrations.

In addition, if I do a 'rake data:migrate:status' after successfully running the migration, the status comes back as 'down', vs 'up'. This is most likely, because the version was listed in the wrong table, to begin with.

I tried building the migration without the '--skip-schema-migration' flag, and got the same results.

Fyi, here is my table info:

abc_development=# \d schema_migrations
Table "public.schema_migrations"
Column | Type | Modifiers
---------+------------------------+-----------
version | character varying(255) | not null
Indexes:
"unique_schema_migrations" UNIQUE, btree (version)

abc_development=# \d data_migrations
Table "public.data_migrations"
Column | Type | Modifiers
---------+------------------------+-----------
version | character varying(255) | not null
Indexes:
"unique_data_migrations" UNIQUE, btree (version)

How can I fix this?

Thanks,
Martin

Conditional migrations capistrano task sometimes ignores changes

I believe there is a small bug in the checking condition in the Capistrano task that runs migrations conditionaly.

if conditionally_migrate && (
    test("diff -q #{release_path}/db/migrate #{current_path}/db/migrate") ||
    test("diff -q #{release_path}/db/data #{current_path}/db/data")
  )
  info '[deploy:migrate] Skip `deploy:migrate` (nothing changed in db/migrate or db/data)'
else
  info '[deploy:migrate] Run `rake db:migrate:with_data`'
  invoke :'deploy:migrating_with_data'
end

From the SSHkit code it seems that the test method returns true when the given command exits gracefully (i.e. when the diff tool finds no changes in the compared directories). But the condition here will succeed even if one of the directories (schema or data migrations) differs due to the || operator, thus preventing running migrations unless both directories differ.

I believe there should be an && operator in the condition instead, skipping migrations only if none of the two migration dirs differ.

I can make a PR if you like. Thanks for this wonderful gem!

Is there support for multitenancy?

I'm using Postgres with multiples schemas, and after executing a data migration, a table data_migrations was created just for the public schema, not for the others.

Rails 6 compatibility

I know rails 6 is still in beta so just opening this issue to track the rails 6 compatibility. Here is the error in rails 6

Traceback (most recent call last):
	49: from bin/rails:10:in `<main>'
	48: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:297:in `require'
	47: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:263:in `load_dependency'
	46: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:297:in `block in require'
	45: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
	44: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in `require_with_bootsnap_lfi'
	43: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
	42: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `block in require_with_bootsnap_lfi'
	41: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require'
	40: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/railties-6.0.0.beta3/lib/rails/commands.rb:18:in `<main>'
	39: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/railties-6.0.0.beta3/lib/rails/command.rb:46:in `invoke'
	38: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/railties-6.0.0.beta3/lib/rails/command/base.rb:65:in `perform'
	37: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	36: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	35: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	34: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/railties-6.0.0.beta3/lib/rails/commands/server/server_command.rb:136:in `perform'
	33: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/railties-6.0.0.beta3/lib/rails/commands/server/server_command.rb:136:in `tap'
	32: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/railties-6.0.0.beta3/lib/rails/commands/server/server_command.rb:139:in `block in perform'
	31: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:297:in `require'
	30: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:263:in `load_dependency'
	29: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:297:in `block in require'
	28: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
	27: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in `require_with_bootsnap_lfi'
	26: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
	25: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `block in require_with_bootsnap_lfi'
	24: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require'
	23: from /Users/hemantv/goodly/config/application.rb:8:in `<main>'
	22: from /Users/hemantv/.rvm/rubies/ruby-2.6.0/lib/ruby/2.6.0/bundler.rb:114:in `require'
	21: from /Users/hemantv/.rvm/rubies/ruby-2.6.0/lib/ruby/2.6.0/bundler/runtime.rb:65:in `require'
	20: from /Users/hemantv/.rvm/rubies/ruby-2.6.0/lib/ruby/2.6.0/bundler/runtime.rb:65:in `each'
	19: from /Users/hemantv/.rvm/rubies/ruby-2.6.0/lib/ruby/2.6.0/bundler/runtime.rb:76:in `block in require'
	18: from /Users/hemantv/.rvm/rubies/ruby-2.6.0/lib/ruby/2.6.0/bundler/runtime.rb:76:in `each'
	17: from /Users/hemantv/.rvm/rubies/ruby-2.6.0/lib/ruby/2.6.0/bundler/runtime.rb:81:in `block (2 levels) in require'
	16: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
	15: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in `require_with_bootsnap_lfi'
	14: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
	13: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `block in require_with_bootsnap_lfi'
	12: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require'
	11: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/data_migrate-5.3.2/lib/data_migrate.rb:27:in `<main>'
	10: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:297:in `require'
	 9: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:263:in `load_dependency'
	 8: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activesupport-6.0.0.beta3/lib/active_support/dependencies.rb:297:in `block in require'
	 7: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
	 6: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in `require_with_bootsnap_lfi'
	 5: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
	 4: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `block in require_with_bootsnap_lfi'
	 3: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/bootsnap-1.4.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require'
	 2: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/data_migrate-5.3.2/lib/data_migrate/migration.rb:1:in `<main>'
	 1: from /Users/hemantv/.rvm/gems/ruby-2.6.0/gems/data_migrate-5.3.2/lib/data_migrate/migration.rb:2:in `<module:DataMigrate>'
/Users/hemantv/.rvm/gems/ruby-2.6.0/gems/activerecord-6.0.0.beta3/lib/active_record/migration.rb:529:in `inherited': Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for: (StandardError)

  class DataMigrate::Migration < ActiveRecord::Migration[4.2]

Is there equivalent of db/schema.rb and rake db:schema:load?

Hello,

Great project! Was wondering how you'd recommend dealing with scenarios where you've the drop the entire database and start from scratch?

Currently what I'm doing for regular migrations is:

  rake db:drop
  rake db:create
  rake db:schema:load
  rake db:seed
  rake db:test:prepare

Is there something similar (rake db:schema:load) I can do for data migrations, ie not not run all the migrations in data/ folder, but restore it to the last known version?

Thanks!

Loosen restriction on file names to be consistent what Rails supports

For schema migrations, rails allows any filename that starts with a number followed by an underscore.

https://github.com/rails/rails/blob/15ef55efb591e5379486ccf53dd3e13f416564f6/activerecord/lib/active_record/migration.rb#L1103-L1105

i.e. db/migrate/1001_my_migration.rb is a valid file name for a migration.

Data-migrate though, requires that the version number be exactly 14 digits long:

# only files matching "20091231235959_some_name.rb" pattern

Rails 5.2.0.rc1 breaks data migrations

Just a heads up, not a fix (unfortunately): Migrations have been refactored to better support multiple databases which breaks all data migration tasks.

rails/rails@a2827ec

Result of running the data:migrate task:

NoMethodError: undefined method 'migrate' for DataMigrate::DataMigrator:Class
.../gems/data_migrate-3.4.0/tasks/databases.rake:249:in 'block (2 levels) in <main>'

rails: 5.2.0.rc1
data_migrate: 3.4.0

Maintanence

Hello there,

Do you need any help with maintaining this gem? We would love if you could merge #21 so I wouldn't have to use a private fork.

Can you please merge this or handout the maintenance to someone else ( me or @janvarljen).

Thank you!

Rollback doesn't work well

From #83

It looks like this happens because: (when the latest 'up' migration is different from the latest migration)

migrator.current_version returns nil in DataMigrate::MigrationContext#move
because migrator.current_version returns the latest migration even if it is 'down', while MigrationContext#current_version returns the latest 'up' migration as expected.

I also noticed that even before rails5.2 changes, it doesn't always work well

Data migration is not correctly placed when trailing slash is not present

Actually is possible to change database migrations path like below but accidentally I realized that there is no a fall back in cases of absent trailing slash.

DataMigrate.configure do |config|
  config.data_migrations_path = "db/path"
end

Current behavior

  • Generates database migrations in db/

Expected behavior

  • Generates database migrations in db/path/

There is an issue for Rails 4.2.5.2

Maybe it's not related to rails version. But it seems like that.
I run 'rake db:migrate:with_data'

NoMethodError: undefined method group_by' for "db/data":String /home/ruslan/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.5.2/lib/active_record/migration.rb:1016:invalidate'
/home/ruslan/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.5.2/lib/active_record/migration.rb:923:in initialize' /home/ruslan/.rvm/gems/ruby-2.3.0/gems/data_migrate-2.0.1/tasks/databases.rake:315:innew'
/home/ruslan/.rvm/gems/ruby-2.3.0/gems/data_migrate-2.0.1/tasks/databases.rake:315:in pending_data_migrations' /home/ruslan/.rvm/gems/ruby-2.3.0/gems/data_migrate-2.0.1/tasks/databases.rake:311:inpending_migrations'
/home/ruslan/.rvm/gems/ruby-2.3.0/gems/data_migrate-2.0.1/tasks/databases.rake:12:in block (3 levels) in <top (required)>' /home/ruslan/.rvm/gems/ruby-2.3.0/gems/airbrake-5.1.0/lib/airbrake/rake/task_ext.rb:19:inexecute'
/home/ruslan/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in eval' /home/ruslan/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in

'

run together with db migrate

is it possible to run together with migration based on timestamp order?
eg. I have db migrations
migration_A_000001
migration_B_000003
and data migraiton:
data_migration_X_000002
is it possible to run it in following order: A, X, C,
best regards

Migration naming conflict

Currently when trying to create a new migration using an exisiting name, we got a conflict error IMO migration names shouldn't matter since we are prepending the timestamp.
See:

rake data:migrate:status
...
  down    20190308223534  Update istopafib message conditions
   up     20190308232550  Update profile measurements
  down    20190312174838  Parse sugar survey
  down    20190313171701  Brainehealth delete duplicated msg trigger

and then:

rails g data_migration parse_sugar_survey                                              [ruby-2.5.0p0]
Running via Spring preloader in process 3828
    conflict  db/data/20190313213844_parse_sugar_survey.rb
Another migration is already named parse_sugar_survey: /webapps/app/db/data/20190312174838_parse_sugar_survey.rb. Use --force to replace this migration or --skip to ignore conflicted file.

Data migrate issue

Hi @ilyakatz

I have created db migration and data migration with rails g data_migration AddStatusToUsers

After I put to db migration

add_column :users, :status, :string

Also I put to data migration

User.update_all(status: 'offline')

After I run rake db:migrate:with_data

And it run only db migration. It ignored my data migration.

Please could you take a look.

Release 5.3.0 published to RubyGems is not up-to-date

Hello,

I'm really happy that the paths to migration files are now configurable.
The problem is that the most recent version of the gem, in which the issue has been resolved, hasn't been pushed to rubygems.org. Version 5.3.0 has been pushed to https://rubygems.org/gems/data_migrate/versions/5.3.0 on 10th December, but there was an additional commit 47c6aca one day later.
The commit by @EnomaDebby was called update changelog, but apart from updating the changelog it modified the code in an important way.
Could you please re-release the gem with latest modification?

Thank you!

rails data:migrate:status is taking files with different extension

If you're using an editor such as vim, it generates Swap files and when you run:

rails data:migrate:status

It take the .swp files as part of the data/ files. IMHO the command should take only files with .rb extension cause in my scenario, the output looks odd:

╰─➤  ls -la db/data

4096 Nov 27 22:19 .20181128000207_add_this_to_that.rb.swp
134 Nov 27 21:49 20181128000207_add_this_to_that.rb
╰─➤  rails data:migrate:status

database: eureka_development

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20181128000207  Add this to that
  down    20181128000207  Add this to that

Testing for Rails 5

Now that Rails 5 has been out for over a month, we should probably test compatibility.
I am using Rails 5 on a project, this might be an opportunity for me to test it out but it would be nice to have multiple data points so we can ensure things are not broken.

If schema and data migration have the same name, the schema migration is executed twice

I have two migrations:

migrate/timestamp1_some_migration_name.rb
data/timestamp2_some_migration_name.rb

Both have the same name, but with different timestamps. If I run rails db:migrate:with_data, the schema migration is executed correctly, but when running the data migration, it tries to run the schema migration again.


== Schema =====================================================================
== 20190328154404 SomeMigrationName: migrating ==============
-- add_column(:some_table, :some_column_id, :integer)
   -> 0.0021s
-- add_column(:some_table, :some_column_type, :string)
   -> 0.0015s
== 20190328154404 SomeMigrationName: migrated (0.0038s) =====

== Data =======================================================================
== 20190328154600 SomeMigrationName: migrating ==============
-- add_column(:some_table, :some_column_id, :integer)
rails aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::DuplicateColumn: ERROR:  column "some_column_id" of relation "some_table" already exists

To make it work I just changed the data migration name. But I think the error may not be the expected behaviour.

Thanks!

Version 3.3.0 Incompatible with SQL Schema Format

The new data_schema file feature added in 3.3.0 results in an error for projects that use config.active_record.schema_format = :sql. The error message is: "only Ruby-based data_schema files are supported at this time".

It seems as if it should be possible to always use the ruby format for the data_schema dump rather than raising an error.

If this line:

case ActiveRecord::Base.schema_format

were changed to reference this method:

def self.schema_file(format = ActiveRecord::Base.schema_format)

which could just return the standard ruby file name, rather than raising an error.

File.join(db_dir, "data_schema.rb")

I'd be happy to submit a PR if that seems like a reasonable approach.

How do I set which data has been migrated?

Hey!

I just found your gem last week and I'm loving it, though I just ran into an issue that I'm not sure if you've solved or not.

When loading the schema from scratch into a database, the schema.rb has a version which (I believe) sets up the schema_migrations table so that the migrations don't run unnecessarily. Since data migrations are stored in the data_migrations table, is there a way to do something similar with this gem? It seems like the data migration will run every time we need to create a new database (which we do a lot)

Migration to Rails 6.0.0.rc1 Throws Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for

Rails version used: 6.0.0.rc1
data_migrate version: 5.3.2

The following error is shown when booting:

	42: from bin/rails:3:in `<main>'
	41: from bin/rails:3:in `load'
	40: from /Users/xxxxx/projects/projectname/bin/spring:15:in `<top (required)>'
	39: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	38: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	37: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/binstub.rb:11:in `<top (required)>'
	36: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/binstub.rb:11:in `load'
	35: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/spring-2.1.0/bin/spring:49:in `<top (required)>'
	34: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client.rb:30:in `run'
	33: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/command.rb:7:in `call'
	32: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/rails.rb:28:in `call'
	31: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/rails.rb:28:in `load'
	30: from /Users/xxxxx/projects/projectname/bin/rails:9:in `<top (required)>'
	29: from /Users/xxxxx/projects/projectname/bin/rails:9:in `require'
	28: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/railties-6.0.0.rc1/lib/rails/commands.rb:18:in `<top (required)>'
	27: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/railties-6.0.0.rc1/lib/rails/command.rb:46:in `invoke'
	26: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/railties-6.0.0.rc1/lib/rails/command/base.rb:65:in `perform'
	25: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	24: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	23: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	22: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/railties-6.0.0.rc1/lib/rails/commands/server/server_command.rb:138:in `perform'
	21: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/railties-6.0.0.rc1/lib/rails/commands/server/server_command.rb:138:in `tap'
	20: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/railties-6.0.0.rc1/lib/rails/commands/server/server_command.rb:141:in `block in perform'
	19: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0.rc1/lib/active_support/dependencies.rb:302:in `require'
	18: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0.rc1/lib/active_support/dependencies.rb:268:in `load_dependency'
	17: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0.rc1/lib/active_support/dependencies.rb:302:in `block in require'
	16: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0.rc1/lib/active_support/dependencies.rb:302:in `require'
	15: from /Users/xxxxx/projects/projectname/config/application.rb:6:in `<top (required)>'
	14: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/bundler.rb:114:in `require'
	13: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/bundler/runtime.rb:65:in `require'
	12: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/bundler/runtime.rb:65:in `each'
	11: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/bundler/runtime.rb:76:in `block in require'
	10: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/bundler/runtime.rb:76:in `each'
	 9: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/bundler/runtime.rb:81:in `block (2 levels) in require'
	 8: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/2.6.0/bundler/runtime.rb:81:in `require'
	 7: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/data_migrate-5.3.2/lib/data_migrate.rb:27:in `<top (required)>'
	 6: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0.rc1/lib/active_support/dependencies.rb:302:in `require'
	 5: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0.rc1/lib/active_support/dependencies.rb:268:in `load_dependency'
	 4: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0.rc1/lib/active_support/dependencies.rb:302:in `block in require'
	 3: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0.rc1/lib/active_support/dependencies.rb:302:in `require'
	 2: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/data_migrate-5.3.2/lib/data_migrate/migration.rb:1:in `<top (required)>'
	 1: from /Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/data_migrate-5.3.2/lib/data_migrate/migration.rb:2:in `<module:DataMigrate>'
/Users/xxxxx/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-6.0.0.rc1/lib/active_record/migration.rb:536:in `inherited': Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for: (StandardError)

  class DataMigrate::Migration < ActiveRecord::Migration[4.2]

I have seen similar tickets in this github repo opened in the past but they didn't give me enough information to solve the issue. Any indications?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.