This project is archived and is in readonly mode.

[PATCH] When environment variable "VERSION" exists, db:migration will fail.

#1203

I use rails-2.1.1 and Windows XP SP3.

I tried the following commands.


rails exampleapp
cd exampleapp
ruby ./script/generate migration user
rake db:migrate

Then, the following errors occurred.


(in D:/rails/exampleapp)
rake aborted!
No migration with version number 2

rails-2.1.1/lib/tasks/databases.rake:99 is the following code, but "VERSION" is set to the environment variable of OS in my environment. ENV["VERSION"] is "2.0.37" and ENV["VERSION"].to_i is "2".


ActiveRecord::Migrator.migrate("db/migrate/", ENV["VERSION"] ? ENV["VERSION"].to_i : nil)

When environment variable "VERSION" exists, and db:migration is used without "VERSION" option, this command will fail.

I added the following descriptions to Rakefile and solved this problem.


ENV["VERSION"] = nil

Could you apply this description beforehand?

Reported by t_yamo · October 11th, 2008 @ 09:22 PM

Activity

DHH
Rails uses that VERSION environment command as way of controlling which migration to go to. Seems that this doesn't work on Windows. If you can make a patch that checks where that ENV comes from and uses the proper one in the case of Windows, that'd be great.

October 30th, 2008 @ 11:55 AM
Gabriel Medina
- Tag set to databases.rake, migrate, migration, migrations, rake, task, version
Actually, the problem is not limited to Windows, this patch fixes this issue, by checking if no VERSION= command line argument is given, resets VERSION env var, and moves original ENV["VERSION"] (if any) to ENV["OS_VERSION"] in case it's ever needed.

Hope this helps.

BTW, while making this patch, tests for railties, fail if you have installed hpricot gem.

first to fail is:
```
def test_gem_adds_load_paths
  @gem.expects(:gem).with(Gem::Dependency.new(@gem.name, nil))
  @gem.add_load_paths
end
```
it expects hpricot dependency to cause it to be loaded, but if hpricot gem is installed, the dependency is met and paths are not changed and gem method is not called, thus the expect fails.

Uninstalling hpricot, makes the tests pass correctly.

I think the tests are outdated, and don't check for the gem being already installed.

Before I try fixing this, I'd like your advice on wether the dependency or the test is wrong, so I know on which one to start looking...

Thanks!

Gabriel Medina.
October 31st, 2008 @ 12:18 AM
Gabriel Medina
- Title changed from When environment variable "VERSION" exists, db:migration will fail. to [PATCH] When environment variable "VERSION" exists, db:migration will fail.
Patch attached.
- env_version_set_breaks_migration.patch 1.34 KB
October 31st, 2008 @ 12:22 AM
Juan Lupión
Wouldn't this patch break setting the VERSION var directly from bash?

VERSION=3 rake db:migrate

October 31st, 2008 @ 07:33 PM
Gabriel Medina
@pantulis: It would. Proposed solution?

October 31st, 2008 @ 07:54 PM
Juan Lupión
Unclear to me, as I can see no way of knowing how the variable was put in the environment, or who set it.

The only other workaround that comes to mind is checking that the VERSION var is only composed of digits. This would catch your specific scenario under Windows but would not be failproof, which your patch is.

October 31st, 2008 @ 08:13 PM
Gabriel Medina
Mhh... that would result in a lot of users having no idea why their migrations go back to N version.

I think an explicit --ignore-env-version or VERSION=HEAD or VERSION=LATEST would do better, don't you think?

And if a migration results in an error of "No migration with version number N", add "maybe you should use --ignore-os-version" or VERSION=HEAD or VERSION=LATEST, and update documentation accordingly...

I'm offering to make the patch, just wanna know which way would be best suited.

November 1st, 2008 @ 08:17 AM
t_yamo
Thanks for all comment. If rails use environment variable, using popular term as variable name is risky. I think most simple (but problematic?) solution is change the variable name from popular term to unique term as like "RAILS_DB_VERSION". This solution have any problem?

November 4th, 2008 @ 02:47 AM
Pratik
- Title changed from [PATCH] When environment variable "VERSION" exists, db:migration will fail. to When environment variable "VERSION" exists, db:migration will fail.
March 8th, 2009 @ 12:44 PM
CancelProfileIsBroken
- State changed from new to wontfix
- Title changed from When environment variable "VERSION" exists, db:migration will fail. to [PATCH] When environment variable "VERSION" exists, db:migration will fail.
Windows does not automatically set ENV["VERSION"], and "2.0.37" is not your Windows version anyhow - on XP it's 5.1.something. The real fix here is to figure out what other software is putting that version in your environment and stop it from doing so.

March 8th, 2009 @ 12:46 PM
t_yamo
Thanks for changing title and status. I know this problem is caused by collision between Rails and other software(this is not XP). So, I resolved this problem by adjusting their software in my environment. But, some people will encounter the same problem. I think real problem is Rails and other software use popular term as environment variable name for own use.

March 9th, 2009 @ 02:32 AM
Gabriel Medina
I agree with t_yamo. It is stubborn to say that Rails is ok with the use of this (and in my opinion ANY environment variable) and this bug wont_fix.

To say that is to have rails features the Windows style.

March 9th, 2009 @ 03:14 AM
Gabriel Medina
Btw, IMHO at least the use of environment variables in rails should be prefixed, like RAILS_ENV.

RAILS_DBMIGRATION_VERSION, RAILS_THIS or RAILS_THAT.

March 9th, 2009 @ 03:17 AM
Ryan Bigg
- Tag cleared.
- Importance changed from to Low
Automatic cleanup of spam.

October 9th, 2010 @ 09:46 PM
bingbing
louis vuitton watches

March 26th, 2011 @ 02:07 AM