Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Error when saving nested polymorphic models in a form #876

Closed
lighthouse-import opened this Issue May 16, 2011 · 2 comments

Comments

Projects
None yet
1 participant

Imported from Lighthouse. Original ticket at: http://rails.lighthouseapp.com/projects/8994/tickets/6478
Created by activestylus - 2011-03-01 15:14:05 UTC

In the case of Person has_many :phones, :as => :phoneable, this happens when I submit a nested form.

Phone(#2157249660) expected, got Array(#2151973780)

You can test it for yourself with this app: https://github.com/activestylus/nested_polymorphic_attributes_bug

On closer inspection it appears the form helpers are not rendering the nested fields correctly, particularly the name attribute:

Looking at the source I see:

<input name="person[phones][number]"...

When I'm pretty sure that should be:

<input name ="person[phones][0][number]"...

FWIW I can build nested models in the console with no problems whatsoever. And the form helpers do not suffer this problem with a regular has_many relationship.

Imported from Lighthouse.
Comment by Josep M. Bach - 2011-02-27 14:01:55 UTC

Seems that the builder doesn't know it's a one-to-many relationship or something like that, could it be?

In this particular line it checks for the [] naming after person[phones] - if it had found it, it would have triggered the #retrieve_auto_index method, which assigns an index ([0], [1]...). Sadly it matches nothing, so I'm guessing someone in the call stack is not checking if person->phones is a 1-n relationship.

Any ideas?

Imported from Lighthouse.
Comment by activestylus - 2011-02-28 15:54:46 UTC

Just tested in 2.3.8 and works fine. Appears to be a Rails 3 issue.

tomstuart pushed a commit to econsultancy/rails that referenced this issue May 17, 2011

primary_key now supports :limit. [#876 state:resolved]
Signed-off-by: wycats <wycats@gmail.com>

tomstuart pushed a commit to econsultancy/rails that referenced this issue May 17, 2011

tomstuart pushed a commit to econsultancy/rails that referenced this issue May 17, 2011

Revert "primary_key now supports :limit for MySQL". Break Sam Ruby app.
To reproduce, start a new application, create a scaffold and run test suite. [#876 state:open]

This reverts commit faeca69.

hisas pushed a commit to hisas/rails that referenced this issue May 9, 2017

Stop collapsing adjacent encodings, fixing whitespace between encoded…
…-words

Adjacent encoded-words with different character sets or encodings would
inadvertently leave valid separator characters (space \x20 or newline \x0A)
as an unencoded part. These characters, per the RFC1342 spec (page 3-4,
"Use of encoded-words in message headers") should not be displayed.

This fix is only for adjacent encoded-words and does not strip the
separator character (linear white-space or newline character) following
encoded words that are then followed by a "word", "text", "ctext", or
"special" (which per the spec should be stripped unless the separator is
a newline that comes at the end of the field.)

Closes #876
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment