I think it's pretty obvious what each method is doing. There is now an "ActiveRecord::Dirty":https://caboo.se/doc/classes/ActiveRecord/Dirty.html module that was added to the ActiveRecord::Base class. Now there are ways to ask the model itself (#changed?, #changes) or ask each attribute individually by just appending the _changed?, _was and so forth. This all looks fine and dandy, but remember: we addressed the first bullet in my list. There is a second problem: *data consistency*. The problem arises when we consider that 2 users could be updating the same model at the same time!! In the older version, this could also happen and the strategy was: _"the last one to update wins."_ Which could not be the best way but at least we could be assured that every attributed in the model would make sense at least from the point of view of one of the users. With this new feature, User A updates 1 attribute., then User B updates 2 different attributes in the same row, and now we have 3 potentially inconsistent columns merged into the same row. This can get out of hand very fast. Database concurrency is not a novel thing. We know at least 2 tricks to make this work, one is "*Pessimistic Locking*":https://api.rubyonrails.org/classes/ActiveRecord/Locking/Pessimistic.html, where the first user acquires a lock from the database and avoids any other user to edit the same row at once. But in a web based system, this is obviously not recommended. The second option is "*Optimistic Locking*":https://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html. The way to enable it is to add a column named 'lock_version' of type integer and with the default initial value of '0'. Now: * User A and User B loads the same row. * User A finished his work first and then updates the row. * The 'lock_version' column is incremented to 1. * Then User B finishes and tries to update, but his operation will fail because the generated SQL update command will search for 'lock_version = 0', but it now changed to '1'. That way we effectively block undesired updates and we give the user a second chance to reload User A's changes and re-evaluate his own changes. This is something to be used sparingly only when it makes sense. Don't go adding 'lock_version' columns at every single table like crazy. Another thing, if for some good particular reason you don't like this new Partial Updates, you can disable it at environment.rb like this: --- ruby ActiveRecord::Base.partial_updates = false # the default is true