грабли дб: миграция прервана!на US-ASCII с использованием граблей 0.9.2.2 и рельсов 3.0.10 - PullRequest
0 голосов
/ 31 декабря 2011

Недавно я обновил свои драгоценные камни и начал добавлять новые вещи в свое приложение, такие как аутентификация сторонними социальными сайтами с использованием omniauth gem.В среде разработки все хорошо и работает как шарм.

Я развертываю на промежуточных и производственных серверах с использованием capistrano.Базовое развертывание в порядке и работает до сих пор, но у меня действительно странные проблемы, когда я хочу выполнить миграцию при развертывании.

Я получаю следующие сообщения об ошибках от capistrano:

    [my.server.com] executing command
*** [err :: my.server.com] rake aborted!
*** [err :: my.server.com] "\xC5" on US-ASCII
*** [err :: my.server.com] 
*** [err :: my.server.com] (See full trace by running task with --trace)
    command finished in 2472ms

Iгуглил все вокруг и не мог найти подходящего решения.Я также попытался снизить рейтинг рейка до 0.8.7, но безуспешно - те же ошибки.

1 Ответ

1 голос
/ 31 декабря 2011

После нескольких часов поиска и поиска я нашел решение, которое (надеюсь) может оказаться полезным для кого-то с похожей или той же проблемой.

Я сделал bundle exec rake --trace db:migrate на промежуточном сервере и получил следующие сообщения об ошибках:

rake aborted!
"\xC5" on US-ASCII
/var/www/myapp/test.myapp.com/releases/20111230233802/config/application.rb:5:in `read'
/var/www/myapp/test.myapp.com/releases/20111230233802/config/application.rb:5:in `<top (required)>'
/var/www/myapp/test.myapp.com/releases/20111230233802/Rakefile:4:in `require'
/var/www/myapp/test.myapp.com/releases/20111230233802/Rakefile:4:in `<top (required)>'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/rake_module.rb:25:in `load'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/rake_module.rb:25:in `load_rakefile'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/application.rb:501:in `raw_load_rakefile'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/application.rb:82:in `block in load_rakefile'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/application.rb:81:in `load_rakefile'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/application.rb:65:in `block in run'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/gems/rake-0.9.2.2/bin/rake:33:in `<top (required)>'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/bin/rake:19:in `load'
/var/www/myapp/test.myapp.com/shared/bundle/ruby/1.9.1/bin/rake:19:in `<main>'

Итак, я запрыгнул в файл config/application.rb, чтобы узнать, что может вызвать ошибку. Строка 5 этого файла загружает внешний файл конфигурации:

require 'yaml'
APP_CONFIG = YAML.load(File.read(File.expand_path('../app_config.yml', __FILE__)))

и этот внешний файл содержит символы UTF-8, а не US-ASCII. Поэтому я попробовал несколько разных решений, чтобы решить эту проблему.

Единственное, что мне помогло, - это добавить несколько строк кода поверх config/application.rb файла:

if RUBY_VERSION =~ /1.9/
  Encoding.default_external = Encoding::UTF_8
  Encoding.default_internal = Encoding::UTF_8
end

только для того, чтобы указать rake загружать внешние файлы в кодировке utf-8. После этого изменения все прошло гладко и точно так, как и ожидалось. Проблема решена!

PS.
Я действительно не знаю, почему разработчики rake 0.9 изменили предыдущее поведение rake 0.8, которое работало хорошо для меня и, вероятно, для вас в течение длительного времени. Может быть, у вас есть идея, почему? Мне очень любопытно.

...