This project is archived and is in readonly mode.

#4137 ✓stale
ronin-82615 (at lighthouseapp)

Dirty checking on serialize attributes hides changes on concurrent updates

Reported by ronin-82615 (at lighthouseapp) | March 9th, 2010 @ 05:15 PM

The solution of #788 to save all serialize attributes creates a problem with concurrent changes on two or more serialized columns. Bug #2397 doesn't solve it either, because it still finds the two defined serialize attributes.

I currently reverted the behaviour to before #788 by commenting out the extra added dirty attributes. Could this become a setting to automaticly add these serialize attributes if needed? Or create a nice way of turning this default behaviour off?

      def update_with_dirty
        if partial_updates?
          # Serialized attributes should always be written in case they've been
          # changed in place.
          update_without_dirty(changed) # | self.class.serialized_attributes.keys)
        else
          update_without_dirty
        end
      end

User Story: I currently have two jquery sorted lists. When an item is dragged to the other list both the lists put an array of ordered integers into the same record. When this is handled concurrent the dirty checking adds both serialize fields by default and updates both fields twice. The last one wins and items are removed or duplicated.

Comments and changes to this ticket

  • ronin-82615 (at lighthouseapp)

    ronin-82615 (at lighthouseapp) March 10th, 2010 @ 08:30 AM

    • Tag changed from active record base dirty update_without_dirty serialize attribute to active, attribute, base, dirty, record, serialize, update_without_dirty
  • ronin-82615 (at lighthouseapp)

    ronin-82615 (at lighthouseapp) March 10th, 2010 @ 08:30 AM

    • Tag changed from active, attribute, base, dirty, record, serialize, update_without_dirty to attribute, base, dirty, record, serialize, update_without_dirty
  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:54 PM

    • State changed from “new” to “open”

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:54 PM

    • State changed from “open” to “stale”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Pages