Rails Ruby on Rails → 3.x

Comments and changes to this ticket

• 

  josh October 28th, 2008 @ 04:25 PM

  • State changed from “new” to “stale”

  Staling out, please reopen if this is still a problem.

• You flagged this item as spam.
  

  bentlegen February 19th, 2009 @ 04:02 AM

  This is still an open issue for our team. Please consider re-opening.

• You flagged this item as spam.
  

  Jörg B. February 23rd, 2009 @ 12:43 AM

  Joshua / or anyone else listening,

  this still -is- a problem (in Rails 2.2.2). Basically I have the following:

  My 'User' model has an explicit 'def to_json' declaration that hides a couple of the model's attributes and also adds a couple methods to the output. All working fine when e.g. doing a @user_instance.to_json

  However, e.g. my photo model belongs_to an user. now when doing a @photo_instance.to_json(:include => [:user]), all my user-class's def to_json get ignored and the full user model is serialized, ignoring my :except and :methods declarations in the user's to_json method.

  So basically yep, the to_json method of included ':include =>[:abc, :def]'s still don't get called.

• You flagged this item as spam.
  

  Seth Ladd February 27th, 2009 @ 08:12 PM

  This is still an issue. I'd like to re-open, but I don't think normal users can.

  Please reopen.

• 

  Matt Jones February 27th, 2009 @ 09:46 PM

  • Tag changed from “activerecord, patch, tested” to “activerecord, bug, to_json”
  • State changed from “stale” to “open”

  @Seth - reopening at your request. I took a look at this, and it does appear that the problem still exists.

  At a quick glance, the fix is going to require changes to: (around line 80, active_record/serialization.rb)

  
  if records.is_a?(Enumerable)
    serializable_record[association] = records.collect { |r| self.class.new(r, opts).serializable_record }
  else
    serializable_record[association] = self.class.new(records, opts).serializable_record
  end
  

  Ideally, it would seem nice to have a hash equivalent to to_json that would return the desired hash without flattening it to a string first.

  Alternatively, one could borrow much of the implementation in xml_serializer.rb, but that's really just a sign that the abstract implementation of add_associations needs to be tweaked.

• You flagged this item as spam.
  

  Ken Collins July 19th, 2009 @ 02:13 AM

  I just had the same issue. I've got a model tree and I just defined to_json(options={}) in each model that add :only defaults and their own :include options. I was hoping that I could go all the way back up the chain at the end of this and just call #to_json on the parent object and was disappointed to some very very odd behavior.

  I also noticed that if I use :only on the top level, it applies it to all levels of :include. I'm searching for other tickets that address this but will try this patch too and let you know.

• You flagged this item as spam.
  

  Ken Collins July 20th, 2009 @ 02:36 PM

  OK, I did some poking around in master this weekend and this is what I found. First, this patch seems outdated with the new plugable JSON backends. Second, giving the new use of how #to_json is really calling #as_json as being the best way to remain JSON agnostic, this ticket may be moot for 3.0. Here is some model examples. So using #as_json in rails 3 does what I would hope and expect.

  @@@ruby

  class Foo
  JSON_ATTRS = [:id,:created_at] has_many :bars def as_json(options=nil)

  attributes.slice(*JSON_ATTRS).merge(:bars => bars)
  

  end end

  class Bar
  JSON_ATTRS = [:id,:owner_id,:owner_type,:etc] has_many :bats def as_json(options=nil)

  attributes.slice(*JSON_ATTRS).merge(:bats => bats)
  

  end end

  class Bat
  JSON_ATTRS = [:not_this,:or_that] def as_json(options=nil)

  attributes.except(*JSON_ATTRS)
  

  end end

  Foo.first.to_json # => Will include all associations defined by model.

• You flagged this item as spam.
  

  Ken Collins July 20th, 2009 @ 02:39 PM

  Better attempt at code formatting

  
  
  class Foo
    JSON_ATTRS = [:id,:created_at]
    has_many :bars
    def as_json(options=nil)
      attributes.slice(*JSON_ATTRS).merge(:bars => bars)
    end
  end
  
  class Bar
    JSON_ATTRS = [:id,:owner_id,:owner_type,:etc]
    has_many :bats
    def as_json(options=nil)
      attributes.slice(*JSON_ATTRS).merge(:bats => bats)
    end
  end
  
  class Bat
    JSON_ATTRS = [:not_this,:or_that]
    def as_json(options=nil)
      attributes.except(*JSON_ATTRS)
    end
  end
  
  
  Foo.first.to_json # => Will include all associations defined by model.
  

• You flagged this item as spam.
  

  will bailey August 7th, 2009 @ 09:10 PM

  It appears that in Rails 2.3.3 the as_json method is not called on ActiveRecord Objects when to_json is called. Is the code example in the previous post only planned to work in Rails 3? I'm wondering what the reasoning is behind not having to_json invoke as_json in active_record/serializers/json_serializer.rb

  I would expect it to work like this:
  

  def to_json(options = {})
    return ActiveSupport::JSON.encode(as_json) if respond_to?(:as_json)
    hash = Serializer.new(self, options).serializable_record
    hash = { self.class.model_name.element => hash } if include_root_in_json
    ActiveSupport::JSON.encode(hash)
  end
  
  # Remove this implement in subclasses as desired
  # def as_json(options = nil) self end #:nodoc:
  

• You flagged this item as spam.
  

  Bart Zonneveld October 7th, 2009 @ 10:35 AM

  +1, although the original patch is apparently outdated.

• You flagged this item as spam.
  

  Jarred Nicholls October 7th, 2009 @ 11:05 PM

  While this is clearly something that wasn't thought hard about (before 2.3.3 and after 2.3.3, irregardless of the new as_json functionality), I came up a simple solution to achieve the same effect until there is a better (more integrated) solution. In fact, this "magic method" solution I came up with could easily be an ActiveRecord::Base class method (much like "serialize" or "attr_protected", etc.) to define a list of attributes that are deemed serializable.

  First I overrode the "serializable_attribute_names" method in ActiveRecord::Serialization::Serializer class:

  module ActiveRecord
    module Serialization
      class Serializer
        def serializable_attribute_names
          attribute_names = @record.respond_to?(:serializable_attributes) ? @record.serializable_attributes : @record.attribute_names
  
          if options[:only]
            options.delete(:except)
            attribute_names = attribute_names & Array(options[:only]).collect { |n| n.to_s }
          else
            options[:except] = Array(options[:except]) | Array(@record.class.inheritance_column)
            attribute_names = attribute_names - options[:except].collect { |n| n.to_s }
          end
  
          attribute_names
        end
      end # class Serializer
    end # module Serialization
  end # module ActiveRecord
  

  Notice the change in the first line of the method, where I check to see if an ActiveRecord responds to "serializable_attributes". If it does, I take the resulting array of attributes from that rather than the "attribute_names" method. This can be the method we implement in our models:

  class User < ActiveRecord::Base
    def serializable_attributes
      # return array of attributes names we deem are safe to serialize
      attribute_names - ["secret_key"]
    end
  end
  

  And Viola!, the net effect we wanted from overriding as_json...only now we are also compatible with XML serialization.

• You flagged this item as spam.
  

  Seth Ladd October 13th, 2009 @ 06:24 AM

  FWIW this is still a problem in Rails 2.3.4. I've created a sample app, with tests, that illustrates this problem.

  http://github.com/sethladd/to_json_busted

• You flagged this item as spam.
  

  Jarred Nicholls October 13th, 2009 @ 03:22 PM

  Yep it is. My code above will make it work as expected if the "expected method" is used, as opposed to overriding as_json. The net effect is the same as what was expected from overriding as_json, as well as working for XML serialization at the same time. I looked into the serialization code and it's not as easy to fix as_json as one would think, without adding JSON serialization logic directly into the Serializer class, which is suppose to be agnostic to the serialization format.

  Hope that helps.

• You flagged this item as spam.
  

  wdlindmeier October 22nd, 2009 @ 07:44 PM

  I made the following patch to Rails 2.2.2 which fixed the problem for JSON serialization.

  
  class ActiveRecord::Base
  
    def to_json_options(options={})
      options.symbolize_keys!
    end        
  
  end
  
  class ActiveRecord::Serialization::JsonSerializer
  
    def initialize(record, options = {})
      super
      @options = @record.to_json_options(@options)
    end
    
  end
  
  class Submission < ActiveRecord::Base
  
    def to_json_options(options={})
      returning(super) do |opts|
        opts[:methods] ||= []
        opts[:methods] = opts[:methods] | ['type', 'photo_urls']
      end
    end
      
  end
  

• You flagged this item as spam.
  

  Aaron Gibralter December 11th, 2009 @ 06:58 AM

  Does anyone know if the next Rails release will address this? It seems like really unexpected behavior for includes to just dump all of the children's attributes willy nilly.

• You flagged this item as spam.
  

  Jarred Nicholls December 11th, 2009 @ 01:37 PM

  Well I have 2.3.5 and this was not addressed. See my solution above - I just overwrote the function that determines what attributes are serializable in ActiveSupport::Serialization::Serializer, and you can add a public method to your models that can return an array of (String) attribute names that can be serialized. This is a fix for both JSON and XML serialization. Of course, this solution doesn't allow for ad hoc decisions on what attributes to serialize when using "include", but it at least makes sure "private" attributes aren't ever included in serialization.

  My suggestion (until "include" will accept attributes to include/exclude for child attributes) is to include a method rather than your ActiveRecord relationship that returns particular attributes of your relationship, and can in turn nest deep into the AR relationship tree. It's not a good solution, it's just a workable solution. The moment you have 3 or more "special methods" because you want different attributes in 3 different situations, you will start to taste vomit in your mouth (I know I would). Until there is an elegant/incorporated solution (which we can certainly roll ourselves and submit as a patch), I've given the above solution to at least be able to exclude secret or unnecessary attributes from our models during serialization (at any level of the "include" hierarchy), and have just learned to live with possibly having too much information in my serialized data.

• You flagged this item as spam.
  

  Aaron Gibralter December 11th, 2009 @ 07:09 PM

  Ah -- true that works -- I also found this plugin, http://github.com/vigetlabs/serialize_with_options, that seems to preserve the options of included associations; that is, if you use serialize_with_options { } for all your models in the includes.

• 

  Jeremy Kemper May 4th, 2010 @ 06:48 PM

  • Milestone changed from “2.x” to “3.x”

  [bulk edit]

• You flagged this item as spam.
  

  kendall (at kendagriff) November 22nd, 2010 @ 05:38 PM

  • Importance changed from “” to “”

  Also having this problem in Rails 3.0.3.

• You flagged this item as spam.
  

  Alex Neth December 16th, 2010 @ 07:31 AM

  Building a json api is a bit of a headache because of this bug.

  I tried to override as_json in each object class, but this only works when as_json/to_json is called directly on an object, not when it is included in another.

  @posts.as_json(:include => :author)

  includes default author properties instead of using the as_json method.

  I ended up creating a static property on my objects and using that wherever necessary, which is in some ways a better solution anyway, since not every serialization will require the same attributes.

• 

  rails March 17th, 2011 @ 12:00 AM

  This issue has been automatically marked as stale because it has not been commented on for at least three months.

  The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

  Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

• 

  rails March 17th, 2011 @ 12:00 AM

  • State changed from “open” to “stale”

• You flagged this item as spam.
  

  Betelgeuse March 17th, 2011 @ 08:00 AM

  Tested with rails 3.0.5 and still broken [state:open].

  in to_json model:
  

    def as_json(options = {})
      options = {
        :include => [:a, :b, :c],
        :except => :a_id
      }
      super options
    end
  

  a: belongs_to
  b: has_many :through
  c: has_many :through

  for a, b, c:
  

    JSON_OPTIONS = {:only =>  [:id, :a] }
  
    def as_json(options = {})
      super JSON_OPTIONS
    end
  

• You flagged this item as spam.
  

  Betelgeuse March 17th, 2011 @ 08:00 AM

  [state: open]

• You flagged this item as spam.
  

  Daniel March 18th, 2011 @ 01:25 PM

  Still broken in 2.3.11 as well.

• You flagged this item as spam.
  

  Daniel March 18th, 2011 @ 01:28 PM

  • State changed from “stale” to “open”

  [state:open]

• You flagged this item as spam.
  

  af001 May 5th, 2011 @ 02:54 AM

  私の中で、総合評価のとっても低いアバアバクロホリスタークロ銀座店。アバクロは大好きなんですけどね。一昨日の東京駅付近での打ち合わせの後、散歩がてら久々に行ってきました。そしたらビックリ！相変わらアバクロず、踊っているだけの店員さんとかもいましたが、