Ah sorry, I shouldn't have assumed edge. My bad.
> This looks likehttp://rails.lighthouseapp.com/projects/8994/tickets/1530
> (where the test Eloy mentions was added).
> That patch has not been released yet, which is probably why Antoine is
> seeing it.
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Eloy Duran
> Sent: 12 January 2009 18:06
> To: firstname.lastname@example.org
> Subject: [Rails-core] Re: tracking_attribute_changes and using default
> checkbox form in the view
> I checked the test cases (dirty_test.rb), and it contains a test for
> this specifically which passes at least on my env.
> def test_nullable_integer_zero_to_string_zero_not_marked_as_changed
> pirate = Pirate.new
> pirate.parrot_id = 0
> # other tests
> pirate.parrot_id = '0'
> assert !pirate.changed?
> Could you check this as well, and otherwise try to extract a small
> piece of code, into a test or sample app, which shows the behaviour?
> If you do so, please file a ticket.
> - Eloy
>> You are right, I have a check box helper (by default, it's sending 0
>> or 1 ) and also my checkbox is represented in my database by an
>> integer ==> 0 means unchecked , 1 means check.
>> So my form is sending 0 because my checkbox is unchecked and before
>> sending, the attribute of the object had the same value 0 (I checked
>> in the database to be sure)
>> So I don't understand why rails tell me the state of this attribute
>> change ? because the attribute is not changing ... 0 ==> 0
>> Best regards,
>>> Sorry, I forgot to add the most important part
>>> What might be happening is that you have a default value of nil
>>> which is then changed to an empty string "". Because the browser
>>> a value because of the gotcha workaround.
>>> So the easiest solution would be to have a default value for the
>>> Which is something you want to have anyways for a boolean field IMO.
>>> - Eloy
>>>> This was probably because you used the check_box helper, which
>>>> sure the browser always sends a value.
>>>> See the documentation for the check_box helper:
>>>> === Gotcha
>>>> The HTML specification says unchecked check boxes are not
>>>> successful, and thus web browsers do not send them. Unfortunately
>>>> this introduces a gotcha: if an Invoice model has a paid flag, and
>>>> in the form that edits a paid invoice the user unchecks its check
>>>> box, no paid parameter is sent. So, any mass-assignment idiom like
>>>> wouldn't update the flag.
>>>> To prevent this the helper generates a hidden field with the same
>>>> name as the checkbox after the very check box. So, the client
>>>> sends only the hidden field (representing the check box is
>>>> unchecked), or both fields. Since the HTML specification says key/