Difference in rails 4 and rails 5 same code acting differently - ruby-on-rails

Question

I have this class in my rails 4, was working perfectly fine :
class Rule < ActiveModelSerializers::Model
# Required by ActiveModelSerializers in order to seralize this object
# #return [Hash] with all the attributes accessible for serialization
def attributes
...some attributes...
end
def initialize(args = {})
super
#some_custom_variable = ...something...
end
# This method is relevant
def assign_attributes(args)
args.each { |k, v| instance_variable_set("##{k}", v) }
some_custom_variable.assign_attributes(args)
end
end
This class is called from the controller create action like so:
rule = Rule.new(permitted_params.symbolize_keys)
rule.save
The problem I have is that assign_attributes is called when executing controller code (I know this because I've put breakpoint inside), this is just happening in rails 5.
So same code, same params in the controller (generated by same tests) behaves differently. And with rails 5, the code never ends up in assign_attributes method.
My question is why does it behave so with rails 5? Why does assign_attributes gets triggered?

Answer 1

In Rails 4, the assign_attributes method was part of ActiveRecord, in Rails 5 it is part of ActiveModel. This change is mentioned in the Rails5 CHANGELOG which everyone reads prior to upgrading Rails.
Presumably, ActiveModelSerializers::Model includes an assign_attributes method via something in ActiveModel and something in ActiveModel thinks it is calling AM's assign_attributes rather than your accidental override.
However, the project is in a state of chaos (to be generous) so it is difficult to trace through the source:
Changes to 0.10.x maintenance:
The 0.10.x version has become a huge maintenance version. We had hoped to get it in shape for a 1.0 release, but it is clear that isn't
going to happen. Almost none of the maintainers from 0.8, 0.9, or
earlier 0.10 are still working on AMS. We'll continue to maintain
0.10.x on the 0-10-stable branch, but maintainers won't otherwise be actively developing on it.
We may choose to make a 0.11.x (
0-11-stable) release based on 0-10-stable that just removes the
deprecations.
What's happening to AMS:
There's been a lot of churn around AMS since it began back in Rails 3.2 and a lot of new libraries are around and the JSON:API spec has reached 1.0.
If there is to be a 1.0 release of AMS, it will need to address the general needs of serialization in much the way ActiveJob can be used
with different workers.
The next major release is in development. We're starting simple and avoiding, at least at the outset, all the complications in AMS
version, especially all the implicit behavior from guessing the
serializer, to the association's serializer, to the serialization
type, etc.
...
That was from six months ago and there is no useful code available on GitHub anymore, the project looks abandoned to me.
A short term fix would be to rename your assign_attributes method. A long term fix would be to replace ActiveModelSerializers altogether, preferable with something that is being actively maintained. The AMS README even offers some alternatives:
jsonapi-rb is a highly performant and modular JSON:API-only implementation. There's a vibrant community around it that has produced projects such as JSON:API Suite.
fast_jsonapi is a lightning fast JSON:API serializer for Ruby Objects from the team of Netflix.

Answer 2

According to both the Rails 4 and Rails 5 docs, there's nothing about whether Rails itself will use assign_attributes. Just that it's a method you can use to assign a bunch of attributes at once.
Rails 4
Allows you to set all the attributes by passing in a hash of attributes with keys matching the attribute names (which again matches the column names).
Rails 5
Allows you to set all the attributes by passing in a hash of attributes with keys matching the attribute names.
Rule.new calling or not calling Rule#assign_attributes is a quirk of the implementation. It's not documented that new will call assign_attributes so you cannot rely on when Rails will call it.
In addition, if you've overriden assign_attributes it's important that it continue to do what it's documented to do. There should be no functional difference between setting each attribute individually and setting them all at once. It appears rather than call super you've written your own mass assignment code, and added your own extra code to mirror the attributes to another object.
There's also the question of how ActiveModelSerializers::Model might be interfering.
If you want to take action when a particular argument is set, instead override the associated attribute= method.
def foo=(value)
...
end
Or use the various ActiveRecord::Callbacks such as before_validation.
Or since it appears you're trying to delegate the mass setting attributes, consider whether delegation is the answer instead.
delegate :this, :that, to: :some_custom_variable