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.