Comments on: Serializing (And Deserializing) Objects With Ruby

By: Probando geoplugin.net desde ruby | Javi Sanromán

Probando geoplugin.net desde ruby | Javi Sanromán — Fri, 29 Jul 2011 11:24:24 +0000

[...] objeto serializado al modo php. Depués de probar la gema json y otros medios de serialización/deserialización de objetos ruby sin éxito, me encuentro con la gema php-serialize que hace justo lo que [...]

By: links for 2011-04-23 « Use You Imagination

links for 2011-04-23 « Use You Imagination — Sat, 23 Apr 2011 15:01:57 +0000

[...] Serializing (And Deserializing) Objects With Ruby (tags: serialization ruby json binary yaml) [...]

By: Inside Ruby on Rails: Serializing Ruby objects with JSON – Simone Carletti's Blog

Thu, 29 Apr 2010 09:35:18 +0000

[...] few weeks ago, Alan Snorkin posted a nice article about serializing objects with Ruby introducing different serialization options, including YAML, Marshaling and JSON. This reminded me [...]

By: ac

ac — Fri, 23 Apr 2010 09:14:33 +0000

i’ve also had problems with yaml and whitespaces.. for example

YAML::load(“\n”.to_yaml) # => “”

for that reason i went with json, only to discover that can’t handle binary payload in strings, so i ended up stripping out all strings to a separate data block and replace them with their index in the data block and length.

(i wanted to also use it with other languages, so marshal wasn’t an option)

By: Tomasz Bak

Tomasz Bak — Fri, 16 Apr 2010 22:12:37 +0000

I used YAML for serializing both reports tempaltes and reports data. The structures were not very complicated, the business case was to have flexibility over defining defects reports in a manufacturing process.

I have experienced occasionally corupted YAML in reports data, which sometimes was hundreds of YAML serialized objects stored in single database text filed (PostgreSQL).

By: LucaB

LucaB — Fri, 16 Apr 2010 08:55:26 +0000

I really enjoyed the post, very useful, as its comments are.
In my recent experience, serialization is fundamental to skip accessing the database during the creation of objects related the current one.
The de-serialization phase is also smooth, I don’t even need to explicitly refer to an array.
For example:

MyClass.write_associated_objects_to_yaml_file (method which access to the database, and use to_yaml) gives me a yaml which already represents an array.

When I do MyClass.read_associated_objects_from_yaml_file, I automatically get an array filled with objects of the right type (MyOtherClass), using “YAML.load_file ‘my_yaml.yml’”.

I only have to be careful and do
load ‘my_other_class.rb’
otherwise I get a bunch of “YAML::Object”s, which are not that useful… :-)

Thanks, this is a very interesting argument,
LucaB

By: Marc-Andre Lafortune

Marc-Andre Lafortune — Fri, 16 Apr 2010 04:04:06 +0000

Marshal provides for mechanism to be backward compatible should you change your data format and need it: just specialize marshal_load and marshal_dump.

By: Marc-Andre Lafortune

Marc-Andre Lafortune — Fri, 16 Apr 2010 04:01:57 +0000

I believe you are mistaken.
First, all implementations of Ruby are mandated to respect the Marshal binary format for a given marshal version. Check RubySpec (core/marshal)
Second, marshal version has changed between 1.8 and 1.9, but it is backward compatible and mostly forward compatible.

By: Korny

Korny — Fri, 16 Apr 2010 03:21:57 +0000

Yeah – that’s why I always prefer something like JSON or YAML – not only are the others implementation dependent, they are my-code-version dependent.
I guess it depends *why* you are serializing data – if it’s only temporary, it’s handy to use Marshal or whatever is fastest. But if it’s not ephemeral data, it’s nice to have a generic format I can de-serialise at any time in the future, even if I’ve changed my object model in the meantime.

By: Delano Mandelbaum

Delano Mandelbaum — Thu, 15 Apr 2010 18:19:50 +0000

That’s true. The other issue with Marshal (and other binary formats) is that you can’t (safely) marshal between versions or implementations of Ruby (e.g. 1.8 to 1.9 or MRI to JRuby).