Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
A JSON serializer should be included by default #194
Here is roughly what it would look like:
# lib/paper_trail/serializers/json.rb require 'active_support/json' module PaperTrail module Serializers class Json def self.load(string) ActiveSupport::JSON.decode string end def self.dump(hash) ActiveSupport::JSON.encode hash end end end end
# lib/paper_trail/serializers/json.rb require 'json' module PaperTrail module Serializers class Json def self.load(string) JSON.parse string end def self.dump(hash) hash.to_json end end end end
@dwbutler - Can you elaborate a bit more on what you mean when you say "It's also more portable (for example, it will automagically pick up MultiJSON.)"? I don't see ActiveSupport::JSON listed as one of the supported JSON engines for MultiJSON (JSON is though). Just curious as to what you think the pro's and con's are of using ActiveSupport::JSON vs. the default JSON gem?
Perhaps it makes sense to just bundle MultiJSON into the library, although, I'm a bit weary of doing that when this will not be the default parser for PaperTrail (at least for now).
I thought about this when I put together the custom serializer code and my conclusion was that changing the serializer was a really uncommon use-case.
My original usecase was to serialize the object_changes into an hstore for Postgres, but on further investigation, it doesn't really quite work straight out of the box as the hash values are all arrays. Having the keys usable is still useful though.
I'd love to hear more usecases, particularly for a JSON serializer. Would we save space by using JSON over YML?
Surprisingly, using JSON over YAML doesn't seem to save space. The strings generated from a JSON dump generally tend to be a bit longer (unless the hash is tiny) due to all the internal quotation marks used in JSON strings.
One argument for the case of providing a JSON parser is the confusion surrounding the fact that Ruby 1.9.2 and 1.9.3 provide two different YAML parsers that behave slightly differently. Due to the confusion that results from this, some users may wish to avoid YAML entirely.
Personally, I haven't run into any issues, but I am confused about what scenario's it still makes sense to use
I feel this is a legitimate argument for providing a JSON serializer.
ActiveSupport::JSON vs JSON gem
JSON vs YAML
The primary reasons I usually pick JSON over YAML are:
Thanks a lot for the thoughtful response! Those are all good reasons that make a better case for
I poked around in the
I also agree that a bit of space saved in the DB is not a huge concern, especially when serializing/deserializing are much faster (not to mention the other reasons you prefer JSON). These all seem like reasons enough for me (to warrant inclusion of JSON serializer in the gem by default)!