ActiveRecord and [] accessors

Currently [] and []= are defined as follows for ActiveRecord
instances:

https://github.com/rails/rails/blob/master/activerecord/lib/active_record/attribute_methods.rb

def [](attr_name)

  read_attribute(attr_name)

end

def []=(attr_name, value)

  write_attribute(attr_name, value)

end

If those accessors are used then overridden attribute accessors

wouldn’t be called.

I didn't find any references about the []/[]= methods in the current

API, so I just mentioned them in docrails:

https://github.com/lifo/docrails/commit/a49fe6ec2cb9f22a3b18d7db5ae2ee90325e9d09

But then I realized that the given example may have undesired side

effects:

[:deleted, :disabled].each{|p| model[p] = params[p] == ‘true’ }

What if "deleted=" or "disabled=" were overridden? They wouldn't be

called.

So I was thinking that maybe Rails 4 could change their

implementation to:

def [](attr_name)

  send attr_name.to_s

end

def []=(attr_name, value)

  send :"#{attr_name}=", value

end

Better to read this style of code in some framework than inside some

application…

Any thoughts?

Happy Easter!

Rodrigo.

They are established aliases to read and write attribute. I know changing would break a ton of my own code and various gems I author.

The whole point of [] and []= is that they alias read/write attribute directly rather than calling overrides. That way you can use them is cases where you don’t want to use the override (or even within your override.)

The intention of [] and []= is so that you can override your model’s accessor.

def username=(username)

self[:username] = username

end

If we fix the []= to call the accessor as well, that will lead to circular reference, and there will be no way to set those variables. You’re also supposed to call the model accessor’s method as well, as those are actually a public interface. [] and []= is not.

  • Prem

Okay, I see that you don’t share the same feelings I have about
this. No problem. Usually I’d want my overridden method to notice
any change to those values and I find annoying have to write code
like this in my controller:

[:deleted, :disabled].each{|p| model.send :"#{p}=", params[p] ==

‘true’ }

There isn't a better alternative to this currently with AR, but as I

said, I’m okay with that and I won’t push this particular discussion
further.

The only thing I'm concerned about is your last statement: "You're

also supposed to call the model accessor’s method as well, as those
are actually a public interface. [] and []= is not."

How can I know what is a public interface or not? Should I revert my

documentation changes in docrails? I mean, if they are not public, I
shouldn’t mention them in the official documentation.

I'm worried about using them in my code and then suddenly Rails

deciding to not making them available in future releases.

I mean, is it reliable for me to keep using such interface instead

of read/write_attribute?

Best,

Rodrigo.

model.update_attributes(params.slice(:deleted, :disabled)).

And let your model handle the conversion of attribute values.

Robert Pankowecki

This is not equivalent.

First, update_attributes will attempt to save the record, but it

wasn’t time to save it yet in my action.

I can't let the model handle the conversion because I'm converting a

Grails application to Rails in parts, so the views are actually
implemented in Grails at this moment and the parameters are being
set by JavaScript, so I can’t be sure they’ll fit the Rails default
rules for casting to boolean. I need to be sure that only ‘true’
should be handled as a true value for this request.

I'm using a proxy for redirecting the new implementation to the

Rails application. I’ve been willing to convert this application to
Rails for a long time, but I never had the chance. But last week I
found a critical bug in Grails and I couldn’t find any workaround to
it:

http://jira.grails.org/browse/GRAILS-8994

So, I decided to take this path for fixing the application. First I

needed to make sure I was able to handle authentication and
authorization the same way.

For that I implemented an action in the Grails application that

would return me the id of the logged in user. Then all I had to do
was:

require 'open-uri'

user_id = open(user_id_url, 'Cookie' =>

“JSESSIONID=#{cookies[‘JSESSIONID’]};
rememberMe=#{cookies[‘rememberMe’]}”).read.to_i

I created a new Devise authentication strategy and this part was

completed so that I could focus in the fix for the buggy Grails
action.

Also I had to change the Devise session routes to match those of the

Grails application.

And finally, since the cookies are specific to the context path, I

needed my Rails application to be mounted in the same context path.
So I tried the instructions in the Configuring Rails guide, but it
didn’t work for me:

https://github.com/rails/rails/issues/5754

And I had to make some more changes to Devise routes as well as

putting all my routes inside the context path namespace.

So now I'm able to convert the Grails application to Rails in small

steps and that is great! :slight_smile:

Actually my current authentication setup is a bit different and I

handle the rememberMe cookie directly. Since I use the Shiro library
to decrypt the cookie and I didn’t want to implement everything in
Ruby nor use JRuby on Rails as it is a slow platform for
development, I implemented the authentication service using JRuby
and Drb and created another strategy using the Drb client for
handling the rememberMe cookie without requiring the Grails
application to be alive for remembered sessions.

Well, anyway I'll try to write an elaborate article on the details

of this setup for anyone else willing to take the same approach as
me for converting an application to Rails.

But in those cases, the Rails API doesn't help much on dealing with

such special cases where the Rails conventions are not always
followed.

Currently I don't override any property, but I wouldn't like to have

to remember that I’m bypassing any overrides if I decide to do so in
the future…

I mean, if there is an override, there is a reason for it to

exist… They shouldn’t be just bypassed.

Best,

Rodrigo.

You can use the same code with a call like:

model.attributes = {}

where the example was update_attributes({}). That won’t attempt to save the model. And either of those calls will assign with any overridden accessors too, so you won’t be bypassing them.

James Coleman

Hi James, thank you for the follow ups. Actually I was already using
attributes= combined with this:

http://api.rubyonrails.org/classes/ActiveModel/MassAssignmentSecurity/ClassMethods.html

But I wasn't aware that it would call the overridden methods. Thanks

for getting that to my attention. I’ve just taken a look at the
sources to be sure:

https://github.com/rails/rails/blob/ceb33f84933639d3b61aac62e5e71fd087ab65ed/activerecord/lib/active_record/attribute_assignment.rb#L33

Thanks :)

Rodrigo.