Rails core - Feb 2009 - 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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Feb 20, 7:39 pm, i am jbarket <jbar...@sleepunit.com>
wrote:
> 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/20...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

On Feb 21, 9:28 am, Chris Cruft <c...@hapgoods.com>
wrote:
> 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
>
> On Feb 20, 7:39 pm, i am jbarket <jbar...@sleepunit.com> wrote:
>
> > 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/20...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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)


On Sat, Feb 21, 2009 at 12:22 PM, i am jbarket
<jbarket@sleepunit.com>wrote:
>
> 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.
>
> On Feb 21, 9:28 am, Chris Cruft <c...@hapgoods.com> wrote:
> > 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
> >
> > On Feb 20, 7:39 pm, i am jbarket <jbar...@sleepunit.com> wrote:
> >
> > > 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/20.
> ..
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

On Feb 21, 12:22 pm, i am jbarket <jbar...@sleepunit.com>
wrote:
> 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.
>
> On Feb 21, 9:28 am, Chris Cruft <c...@hapgoods.com> wrote:
>
> > 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
>
> > On Feb 20, 7:39 pm, i am jbarket <jbar...@sleepunit.com> wrote:
>
> > > 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/20...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---