PATCH: Support for String Lists in Mass Assignment of Associations via association_ids=

Hey guys,

I've got a very minor patch up. Tests for assocation_ids= still work fine with these changes.

Basically, some things send params for multiselects and such as ["1,2,3,4"] and, while it might be possible to make sure that these things handle what they send on their own, it seems like something Rails should easily be able to deal with.

The patch verifies the format and, if it finds something like this, it converts it to the [1,2,3,4] Rails would prefer.

Thanks for taking a look guys.

http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2032-support-for-string-lists-in-mass-assignment-of-associations-via-assocation_ids

It seems like this conversion would be better handled in the controller or model.

Using anything other than integer primary keys also becomes riskier. So far Rails has done a pretty good job of permitting non-integer keys. I would hate to see that fall by the wayside.

-1

The problem is that it can't be handled in the model with a before_save because the data has already been converted (and thus destroyed), and handling it in the controller is messy.

I'm curious if you actually looked at the diff. It's quite short. All it does it in the instance of adding multiple items to a many to many relationship at once, it converts a _specific_ set... ["1,2,3,4"] to [1,2,3,4]. It wouldn't do anything to ["A,B,C,D"] or anything else you could dream of that is nonstandard.

Why not just #map(&:to_i) the params in question?

Assuming params[:foo] is an array of integers cast as strings:

@object.association_ids = params[:foo].map(&:to_i)

I did look at the diff and in particular noticed the Regexp looking for digits separated by comma. That might cause problems with aggressively string encoded UUIDs, for example. And you can override your association_ids= setter as noted by someone else on Lighthouse. You could even create a plugin for this -I've got a whole pile of plugins that I consistently use with HMT associations -standard Rails doesn't go very far with specific semantics there and I'm always looking to deal with things like reordering the set, appending to the set with weak update semantics, etc.