#1326 ✓resolved

dm-rails db:migrate/db:automigrate should only migrate the database for the current environment

Reported by Postmodern | June 17th, 2010 @ 04:59 AM

dm-rails db:migrate and db:automigrate tasks do not conform to the behavior of the Rails3 ActiveRecord db:migrate task. When running db:migrate/db:automigrate with dm-rails, dm-rails attempts to migrate the development and testing databases. This also causes tasks such as rake spec to migrate away your development database.

The Rails db:migrate task has traditionally migrated the database for the current environment. If the environment was not specified by RAILS_ENV, it would be defaulted to development.

Correct behavior:

$ rails new rails_ar
$ cd rails_ar
$ bundle install
$ rm db/*.sqlite3
$ rake db:migrate
(in /home/hal/rails_ar)
$ ls db/
development.sqlite3  schema.rb  seeds.rb

Incorrect behavior:

$ cd rails_dm
$ bundle install
$ rails generate model User name:string
$ rm db/*.sqlite3
$ rake db:automigrate
$ ls db/
development.sqlite3  seeds.rb  test.sqlite3

Comments and changes to this ticket

  • Martin Gamsjaeger (snusnu)

    Martin Gamsjaeger (snusnu) June 17th, 2010 @ 07:23 AM

    • State changed from “new” to “accepted”

    Actually, I'm not sure. I mean, I'm kinda decided that it should behave like you think it should (and I even tweeted about that some time ago http://twitter.com/snusnu/status/15801518236

    The thing is, rails3 (AR) started specifically doing this at some point. I'm sure about that. I haven't checked if they maybe reverted that in the meantime, but I'm sure the behavior was like that at some point in the near history.

    Anyway, I don't want it to behave like that either, it doesn't make sense for DM. I will fix it (in fact, dm-config doesn't show that behavior anymore iirc).

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 17th, 2010 @ 09:19 AM

    • State changed from “accepted” to “resolved”

    (from [8bf64e7d18d73b4ac781ab4a1e882919c3292514]) Behave like AR does wrt migrating dev and test storages

    This change makes some rake tasks behave like so:

    rake db:create # both dev and test repos rake db:drop # only the current env repo rake db:automigrate # only the current env repo rake db:autoupgrade # only the current env repo rake db:migrate # only the current env repo

    Previously, db:drop/automigrate/autoupgrade were
    operating on both dev and test repos if RAILS_ENV
    was set to development.

    While creating both dev and test repos when no
    RAILS_ENV is specified (defaults to development)
    makes sense, it doesn't make sense to perform the
    other operations on both repo envs too.

    [#1326 state:resolved] http://github.com/datamapper/dm-rails/commit/8bf64e7d18d73b4ac781ab...

  • Martin Gamsjaeger (snusnu)

    Martin Gamsjaeger (snusnu) June 17th, 2010 @ 09:20 AM

    You were right, I mixed it up and added the operation in too many cases (rails3 creates both storages, but doesn't affect both in any other tasks). dm-rails as of http://github.com/datamapper/dm-rails/commit/8bf64e7d18d73b4ac781ab... should behave the same now.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Referenced by