Обновленное приложение Rails до Ruby 1.9.2 - класс DateTime должен иметь метод `_load ' - PullRequest
Новая
       16

Обновленное приложение Rails до Ruby 1.9.2 - класс DateTime должен иметь метод `_load '

1 голос
/ 22 февраля 2012

Поскольку я обновил свое приложение до ruby ​​1.9.2, я получил следующую ошибку:

Я использую ruby ​​-v ruby ​​1.9.2p290 (редакция 2011-07-09, 32553) [x86_64-darwin11.2.0] 

TypeError (class DateTime needs to have method `_load'):
  activesupport (3.2.1) lib/active_support/message_verifier.rb:45:in `load'
  activesupport (3.2.1) lib/active_support/message_verifier.rb:45:in `verify'
  actionpack (3.2.1) lib/action_dispatch/middleware/cookies.rb:288:in `[]'
  actionpack (3.2.1) lib/action_dispatch/middleware/session/cookie_store.rb:53:in `block in unpacked_cookie_data'
  actionpack (3.2.1) lib/action_dispatch/middleware/session/abstract_store.rb:55:in `stale_session_check!'
  actionpack (3.2.1) lib/action_dispatch/middleware/session/cookie_store.rb:51:in `unpacked_cookie_data'
  rack (1.4.1) lib/rack/session/cookie.rb:98:in `extract_session_id'
  actionpack (3.2.1) lib/action_dispatch/middleware/session/abstract_store.rb:51:in `block in extract_session_id'
  actionpack (3.2.1) lib/action_dispatch/middleware/session/abstract_store.rb:55:in `stale_session_check!'
  actionpack (3.2.1) lib/action_dispatch/middleware/session/abstract_store.rb:51:in `extract_session_id'
  rack (1.4.1) lib/rack/session/abstract/id.rb:43:in `load_session_id!'
  rack (1.4.1) lib/rack/session/abstract/id.rb:32:in `[]'
  rack (1.4.1) lib/rack/session/abstract/id.rb:262:in `current_session_id'
  rack (1.4.1) lib/rack/session/abstract/id.rb:268:in `session_exists?'
  rack (1.4.1) lib/rack/session/abstract/id.rb:107:in `exists?'
  rack (1.4.1) lib/rack/session/abstract/id.rb:122:in `load_for_read!'
  rack (1.4.1) lib/rack/session/abstract/id.rb:64:in `has_key?'
  actionpack (3.2.1) lib/action_dispatch/middleware/flash.rb:258:in `ensure in call'
  actionpack (3.2.1) lib/action_dispatch/middleware/flash.rb:259:in `call'
  rack (1.4.1) lib/rack/session/abstract/id.rb:205:in `context'
  rack (1.4.1) lib/rack/session/abstract/id.rb:200:in `call'
  actionpack (3.2.1) lib/action_dispatch/middleware/cookies.rb:338:in `call'
  activerecord (3.2.1) lib/active_record/query_cache.rb:64:in `call'
  activerecord (3.2.1) lib/active_record/connection_adapters/abstract/connection_pool.rb:443:in `call'
  actionpack (3.2.1) lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
  activesupport (3.2.1) lib/active_support/callbacks.rb:405:in `_run__3195440498508246587__call__1658952344890015472__callbacks'
  activesupport (3.2.1) lib/active_support/callbacks.rb:405:in `__run_callback'
  activesupport (3.2.1) lib/active_support/callbacks.rb:385:in `_run_call_callbacks'
  activesupport (3.2.1) lib/active_support/callbacks.rb:81:in `run_callbacks'
  actionpack (3.2.1) lib/action_dispatch/middleware/callbacks.rb:27:in `call'
  actionpack (3.2.1) lib/action_dispatch/middleware/reloader.rb:65:in `call'
  actionpack (3.2.1) lib/action_dispatch/middleware/remote_ip.rb:31:in `call'
  actionpack (3.2.1) lib/action_dispatch/middleware/debug_exceptions.rb:16:in `call'
  actionpack (3.2.1) lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
  railties (3.2.1) lib/rails/rack/logger.rb:26:in `call_app'
  railties (3.2.1) lib/rails/rack/logger.rb:16:in `call'
  actionpack (3.2.1) lib/action_dispatch/middleware/request_id.rb:22:in `call'
  rack (1.4.1) lib/rack/methodoverride.rb:21:in `call'
  rack (1.4.1) lib/rack/runtime.rb:17:in `call'
  rack (1.4.1) lib/rack/lock.rb:15:in `call'
  actionpack (3.2.1) lib/action_dispatch/middleware/static.rb:53:in `call'
  railties (3.2.1) lib/rails/engine.rb:479:in `call'
  railties (3.2.1) lib/rails/application.rb:220:in `call'
  rack (1.4.1) lib/rack/content_length.rb:14:in `call'
  railties (3.2.1) lib/rails/rack/log_tailer.rb:14:in `call'
  rack (1.4.1) lib/rack/handler/webrick.rb:59:in `service'
  /Users/guillaumenm/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
  /Users/guillaumenm/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
  /Users/guillaumenm/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'

Я создал новое приложение rails, никаких проблем с его запуском.У меня не было никаких проблем раньше.

Вот мой гем-файл.Любая помощь будет очень кстати.

Спасибо 

source :gemcutter

gem 'oauth2'
gem 'faraday'
gem "koala", "~> 1.2.0beta"
gem 'json'
gem "rails", "3.2.1"
gem "sqlite3-ruby", :require => "sqlite3" 
gem 'songkickr'
gem 'httparty'
gem "squeel" , "~> 0.9.5" 
group :development do
  gem 'dalli'  #To use memcached
  gem 'newrelic_rpm'
  gem 'rails-web-console', :require => 'console'
  gem 'heroku'
end

gem 'event-calendar', :require => 'event_calendar'
gem 'delayed_job', '2.1.4'
gem 'icalendar'
gem 'acts_as_tree'
gem 'active_scaffold'
gem 'prototype-rails' 
gem 'prototype_legacy_helper', '0.0.0'  , :git => 'git://github.com/rails/prototype_legacy_helper.git'
gem "state_machine"

Просто понизил мое приложение до моих предыдущих рабочих рельсов 3.1.2, успеха больше нет.Связано с обновлением ruby ​​1.9.2.

Ответы [ 3 ]

0 голосов
/ 16 сентября 2013

При обновлении производственного приложения я смог обойти эту проблему, очистив все сеансы:

УДАЛИТЬ ИЗ сеансов;

(из БД с использованием SQL - так что пользователи надеваютне надо очищать их куки)

0 голосов
/ 20 сентября 2013

Нечто подобное произошло со мной недавно.После некоторой отладки (даже отладки кода ruby ​​для подтверждения) я пришел к выводу, что гем plist4r модифицировал класс String, сделав его доступным для пользователя ().После обновления, когда мы удалили нашу зависимость от plist4r, экземпляры String были возвращены обратно в систему для десериализации.Но сериализованные потоки все еще требовали, чтобы экземпляры String были десериализованы пользователем, поэтому возникла ошибка.

Для меня это был случай plist4r и класса String https://github.com/dreamcat4/plist4r/blob/master/lib/plist4r/backend/ruby_cocoa.rb

Могут быть и другие случаи, такие какхорошо.

Решение для нас состояло в том, чтобы аннулировать все сеансы (данные / файлы cookie), устраняя тем самым необходимость десериализации этих потоков.

0 голосов
/ 23 февраля 2012

Нашел ответ по stackoverflow:

Ошибка локального сервера после обновления ruby ​​с 1.8.7 до 1.9.2 (с Rails 3.1.1)

Очистить вашфайлы cookie: ваше приложение хранит сеанс (который представляет собой объект ruby) в файле cookie.Если я правильно помню, он изменил формат маршала между 1.8 и 1.9, поэтому ваше приложение больше не может загружать старые сеансы

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

...