SerializationTypeMismatch when retrieving (not: storing) object

Rails
1

I don’t understand the following example from the ActiveRecord::Base
section in http://api.rubyonrails.org/ :

======
class User < ActiveRecord::Base
serialize :preferences, Hash
end

user = User.create(preferences: %w( one two three ))
User.find(user.id).preferences # raises SerializationTypeMismatch

What was the design choice, that I get the exception in the last line?
I could understand, if there is an exception in User.create, because
:preferences is supposed to be a Hash (if I understood correctly the
‘serialize’ function), and instead an Array is passed. But the
documentation clearly says that the exception happens at retrieval:

======
You can also specify a class option as the second parameter that’ll
raise an exception if a serialized object is retrieved as a descendant
of a class not in the hierarchy.

Is there a deeper reason, why this error is caught at retrieval, and not
already at the time of storing the value?

2

On Thursday, June 12, 2014 8:41:06 AM UTC-4, Ruby-Forum.com User wrote:

User.find(user.id).preferences # raises SerializationTypeMismatch
raise an exception if a serialized object is retrieved as a descendant
of a class not in the hierarchy.

Is there a deeper reason, why this error is caught at retrieval, and not
already at the time of storing the value?

–
Posted via http://www.ruby-forum.com/.

I’m not sure exactly why, but it is true, the error doesn’t get thrown
until you try to retrieve it. Part of the issue is that the serialize
method creates a uniquely ruby construct, to the database it’s a text
field. Therefore, when you save the record, unless there’s logic on the
Rails side, there isn’t going to be an error from the database from a
mismatch.

I’m not fond of serialization for that reason, because you can’t
initialize
the hashes or whatever you store there, and, by definition, it’s limited
to
64K (the limit of a text field). Rails 4 now has the store which, IMO,
is
better if it meets your needs. Also, PostgreSQL now supports hash,
array,
and json column types (I think you need PostgreSQL 9.2 or later).