Rails Ruby on Rails → 2.x

Comments and changes to this ticket

• 

  DHH October 30th, 2008 @ 11:55 AM

  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.

• You flagged this item as spam.
  

  Gabriel Medina October 31st, 2008 @ 12:18 AM

  • 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.

• You flagged this item as spam.
  

  Gabriel Medina October 31st, 2008 @ 12:22 AM

  • 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.3 KB

• You flagged this item as spam.
  

  Juan Lupión October 31st, 2008 @ 07:33 PM

  Wouldn't this patch break setting the VERSION var directly from bash?

  VERSION=3 rake db:migrate

• You flagged this item as spam.
  

  Gabriel Medina October 31st, 2008 @ 07:54 PM

  @pantulis: It would. Proposed solution?

• You flagged this item as spam.
  

  Juan Lupión October 31st, 2008 @ 08:13 PM

  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.

• You flagged this item as spam.
  

  Gabriel Medina November 1st, 2008 @ 08:17 AM

  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.

• You flagged this item as spam.
  

  t_yamo November 4th, 2008 @ 02:47 AM

  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?

• 

  Pratik March 8th, 2009 @ 12:44 PM

  • Title changed from “[PATCH] When environment variable "VERSION" exists, db:migration will fail.” to “When environment variable "VERSION" exists, db:migration will fail.”
• 

  CancelProfileIsBroken March 8th, 2009 @ 12:46 PM

  • 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.

• You flagged this item as spam.
  

  t_yamo March 9th, 2009 @ 02:32 AM

  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.

• You flagged this item as spam.
  

  Gabriel Medina March 9th, 2009 @ 03:14 AM

  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.

• You flagged this item as spam.
  

  Gabriel Medina March 9th, 2009 @ 03:17 AM

  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.

• 

  Ryan Bigg October 9th, 2010 @ 09:46 PM

  • Tag cleared.
  • Importance changed from “” to “Low”

  Automatic cleanup of spam.

• You flagged this item as spam.
  

  bingbing March 26th, 2011 @ 02:07 AM

  louis vuitton watches