Update_attributes updates data from second instance of nested form but not the first

Got a weird situation with an update put to a controller with a form
with
nested attributes.

On the data below, I am updating data for both items (‘0’ and ‘1’) in
rosters_attributes (in the example below I am updating the ‘name’
attribute
to a new value in both cases. What I am stuck on is that ‘1’ gets its
data
updated, regardless of what field I update, while ‘0’ does not get
updated
regardless of the field.

However, update_attributes(params[:matchup]) returns true, so there is
no
error. If the second was not updating I would assume something is wrong
in
my code in terms of attributes getting assigned to a model, but that
does
not seem to be the case.

Parameters: {
“matchup”=>
{
“end_date(3i)”=>“19”, “end_date(4i)”=>“16”, “end_date(5i)”=>“46”,
“rosters_attributes”=>
{
“0”=>
{
“name”=>“abc”, “players_rosters_attributes”=>
{
“0”=>{“player_id”=>“1”, “id”=>“65”},
“1”=>{“player_id”=>“2”, “id”=>“66”},
“2”=>{“player_id”=>“3”, “id”=>“67”},
“3”=>{“player_id”=>“4”, “id”=>“68”}
},
“id”=>“17”
},
“1”=>
{
“name”=>“bcd”, “players_rosters_attributes”=>
{
“0”=>{“player_id”=>“3”, “id”=>“69”},
“1”=>{“player_id”=>“2”, “id”=>“70”},
“2”=>{“player_id”=>“7”, “id”=>“71”},
“3”=>{“player_id”=>“8”, “id”=>“72”}
},
“id”=>“18”
}
},
“release_date(1i)”=>“2012”, “release_date(2i)”=>“5”,
“release_date(3i)”=>“19”, “release_date(4i)”=>“16”,
“end_date(1i)”=>“2012”, “release_date(5i)”=>“46”, “end_date(2i)”=>“5”},
“commit”=>“Update Fantasy matchup”,
“authenticity_token”=>“lAOYIXDYqm965eIyAv4/MXZSTgGSsx11DIea0XLGiZo=”,
“utf8”=>“✓”, “id”=>“9”}

Also, in the server, I see that the first Roster is loading but does not
get
its name updated while the second does.

User Load (0.4ms) SELECT users.* FROM users WHERE users.id =
2
LIMIT 1
UserProfile Load (0.4ms) SELECT user_profiles.* FROM
user_profiles
WHERE (user_profiles.user_id = 2) LIMIT 1
FantasyMatchup Load (0.3ms) SELECT matchups.* FROM
fantasy_matchups
WHERE fantasy_matchups.id = 9 LIMIT 1
SQL (0.1ms) BEGIN
Roster Load (0.3ms) SELECT rosters.* FROM rosters WHERE
rosters.id IN (17, 18) AND (rosters.matchup_id = 9)
# This does not update but should

  • PlayersRoster Load (0.3ms) SELECT players_rosters.* FROM
    players_rosters WHERE players_rosters.id IN (65, 66, 67, 68) AND
    (players_rosters.roster_id = 17)
    CACHE (0.0ms) SELECT matchups.* FROM fantasy_matchups WHERE
    fantasy_matchups.id = 9 LIMIT 1
  • SQL (0.7ms) SELECT COUNT() FROM rosters INNER JOIN bets ON
    bets.roster_id = rosters.id WHERE (rosters.matchup_id = 9)
    CACHE (0.0ms) SELECT matchups.
    FROM fantasy_matchups WHERE
    fantasy_matchups.id = 9 LIMIT 1
    CACHE (0.0ms) SELECT COUNT() FROM rosters INNER JOIN bets ON
    bets.roster_id = rosters.id WHERE (rosters.matchup_id = 9)

This updates*

  • PlayersRoster Load (0.4ms) SELECT players_rosters.* FROM
    players_rosters WHERE players_rosters.id IN (69, 70, 71, 72) AND
    (players_rosters.roster_id = 18)
    AREL (0.4ms) UPDATE rosters SET name = ‘bcd’, updated_at =
    ‘2011-05-19 17:12:53’ WHERE rosters.id = 18
  • SQL (0.8ms) COMMIT

Any ideas, anyone?

Thanks,

David

I have resolved this:

The situation was that update_attributes was only working on the second
record in a nested form arrangement. To fix this problem I found that if
I
do this:

@matchup = Matchup.includes(:rosters).where(“matchups.id
=#{params[:id]}”).first

Rather than

@matchup = Matchup.find(params[:id])

All associated records update via the nested arrangement.

So now when I run @matchup.upate_attributes(params[:matchup]), it
updates
all records (and I have three levels of nested forms below the principal
record).

I assume that the problem was that using the #find method that for some
reason that update_attributes might be having a problem with the
associations not having loaded, where when I include the first main
association and then call #first, the whole record (and apparently
associated records) are loaded… given that when I implement the above,
all
the other associations start to update correctly.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs