In the initializer makes sure that only attributes defined by the serializer, using accessors ( attr_accessor), are committed to the DB. # models/concerns/serializable.rb module Serializable extend ActiveSupport::Concern def initialize(json) unless json.blank? if json.is_a?(String) json = JSON.parse( json) end # Will only set the properties that have an accessor, # such as those provided to an attr_accessor call. Our custom JSON serializer FacebookProfileData is using an ActiveRecord concern that can be shared with other models as well.
serialize :facebook_profile_data, FacebookProfileData end # models/facebook_profile_data.rb class FacebookProfileData attr_accessor :object_id, :profile_image_url include Serializable end Enter custom serializers: # models/user.rb class User < ApplicationRecord #.
#Rails db text vs string code#
The idea is that while our data may be unstructured and loose, our code should enforce some rigidity. We should also prevent random JSON from being added to our column. Sometimes we might use JSON columns not necessarily because the data is unstructured but just because we don’t want to create a whole new table and normalize: avoid joins and thus optimize queries. facebook_profile_data = 'new-object-id' user.save def change add_column :users, :facebook_profile_data, :json end # user.rb class User '.', 'profile_image_url' => '.'} user. Rails makes them a breeze to work with: # Migration for adding a JSON column to the users table. JSON columns in MySQL, Postgres etc can solve these problems while staying within the relational paradigm. But there was also a legitimate need for an unstructured solution to specific problems, like storing user settings, API responses, change logs, health records etc.
I think these digressions were in part fashionable consumption. Ever since the NoSQL boom, there were unnecessary jumps made to embrace Mongo, Cassandra etc as primary datastores for applications that probably would’ve been fine with an RDBMS instead.
0 kommentar(er)
