ActiveSupport::TimeWithZone serialization format in 5.x.x is not backward compatible with 4.x.x #26296
Comments
|
r? @pixeltrix |
|
@kwent as you say your problem is that you've got AS::TWZ instances that are serialized by a Rails 5.0 application being read by a Rails 4.2 application as the other way round it's not a problem since they get read as standard Ruby UTC Time instances. I think you're going to have to patch either your Rails 5.0 application or Rails 4.2 application to make the values compatible with each other. Fixing it so Rails 4.2 can read them might seem possible but you're still going to have issues because those instances will be serialized in the 4.2 format because we can't change how they're being written in a patch release. Put the following code in an initializer in your Rails 4.2 applications and everything should work: # https://github.com/rails/rails/issues/26296
ActiveSupport::TimeZone.class_eval do
def init_with(coder) #:nodoc:
initialize(coder['name'])
end
def encode_with(coder) #:nodoc:
coder.tag ="!ruby/object:#{self.class}"
coder.map = { 'name' => tzinfo.name }
end
end
ActiveSupport::TimeWithZone.class_eval do
def init_with(coder) #:nodoc:
initialize(coder['utc'], coder['zone'], coder['time'])
end
def encode_with(coder) #:nodoc:
coder.tag = '!ruby/object:ActiveSupport::TimeWithZone'
coder.map = { 'utc' => utc, 'zone' => time_zone, 'time' => time }
end
endUsually in these kinds of situations we'll do forward migration, e.g. when we introduced JSON session serialization in 4.1 we offered a hybrid that would read existing serializations and convert them but not a backwards migration where a JSON session created in 4.1 would work with a 4.0 application. HTH and sorry for any bother caused. |
|
Well i did the opposite. I patched my 5.0.0.1 Rails app to write this object as Rails 4.2 would do by copying and add this file to my initializer. Works too ! https://github.com/rails/rails/blob/4-2-stable/activesupport/lib/active_support/time_with_zone.rb Thanks for the feedback. Regards, |
It is helpful to be able to run apps concurrently written in successive versions of Rails to aid migration, e.g. run Rails 4.2 and 5.0 variants of your application at the same time to carry out A/B testing. To do this serialization formats need to be cross compatible and the change in 3aa26cf didn't meet this criteria because the Psych loader checks for the existence of init_with before setting the instance variables and the wrapping behavior of ActiveSupport::TimeWithZone tries to see if the Time instance responds to init_with before the @time variable is set. To fix this we backported just the init_with behavior from the change in 3aa26cf. If the revived instance is then written out to YAML again it will revert to the default Rails 4.2 behavior of converting it to a UTC timestamp string. Fixes #26296.
Expected behavior
We have multiple apps using rails
5.0.0.1and rails4.2.7.1and sharing the same database.5.0.0.1is serializing time zone differently than4.2.7.1introduced by this commit.Our app using rails
4.2.x.xare not able to deserialize the new YAML written by our rails5.0.0.1applications.Would be nice if the next
4.2.x.xis able to deserialize the new format.Backtrace
System configuration
Rails version: 4.2.7.1
Ruby version: 2.2.4
The text was updated successfully, but these errors were encountered: