Update callbacks with upstream improvements #1028
Conversation
| end | ||
|
|
||
| def _update_record(_options = {}) | ||
| return false unless content_changed? |
There was a problem hiding this comment.
In 3f213e4, I've changed this from true to false (to cancel after_update callbacks, like we're doing above). It seems like this was introduced in c76c6ca, but it's unclear why create and update are different. @hectorcorrea @jcoyne?
There was a problem hiding this comment.
I disagree, it should return true if there is nothing to save as ActiveRecord does. See https://gist.github.com/jcoyne/074969310111653ae02c
There was a problem hiding this comment.
create record is different because it would not save anything if there is no content to save, that would effectively be an error.
There was a problem hiding this comment.
@cbeer I don't really care what _update_record returns as long as save() returns true in this instance.
There was a problem hiding this comment.
I looked at how Rails handles callbacks -- they don't suppress the after_update hook if nothing changed (and, presumably, neither do we, in AF::Persistence). I've updated this behavior in 5bae75f.
cbeer
force-pushed
the
update-callbacks
branch
3 times, most recently
from
3f213e4
to
c5f5ccb
Compare
| # | ||
| # There's a series of callbacks associated with #destroy!. If the | ||
| # <tt>before_destroy</tt> callback throws +:abort+ the action is cancelled | ||
| # and #destroy! raises ActiveRecord::RecordNotDestroyed. |
There was a problem hiding this comment.
Change this line and the next to ActiveFedora instead of ActiveRecord
… with AF::Callbacks
Rails fires after_update callbacks whether or not the object was changed
Update callbacks with upstream improvements
No description provided.