Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sean's rails 5.1 work, rebased #900

Merged
merged 3 commits into from
Dec 3, 2016
Merged

Sean's rails 5.1 work, rebased #900

merged 3 commits into from
Dec 3, 2016

Conversation

jaredbeck
Copy link
Member

No description provided.

This updates the code to work with Rails 5.1.0.alpha, as of commit
rails/rails@1bdc395.

The biggest change was to call the new methods provided by
`ActiveRecord::Dirty` when needed. In the next version of Rails after
5.1, dirty will be "cleared" before after_save callbacks are run. This
means that code in an after_save callback will behave the same as if it
was run after calling `.save`.

Since the concept of "changed" is fairly nebulous, two new method sets
were introduced with names that specify whether they're operating on
changes from what we think is in the database to what's in memory, or
the changes that were just persisted. Paper trail will now use the
latter set of methods if available and called from an after_ callback.

There were a few other unrelated changes required to get this working on
master. The first was the change from `appear_as_new_record` to
`appear_as_unpersisted`. This was due to a single test that broke as a
result of
rails/rails@c546a2b
where reifying a version with a nil has_one association was persisting the
change to the foreign key. I am actually unsure how that commit caused
the problem (or more specifically, I'm unsure how it was passing
before). However, as best as I can tell, the purpose of
`appear_as_new_record` was to attempt to prevent the callbacks in
`AutosaveAssociation` (which is the module responsible for persisting
foreign key changes earlier than most people want most of the time
because backwards compatibility or the maintainer hates himself or
something) from running. By also stubbing out `persisted?` we can
actually prevent those. A more stable option might be to use `suppress`
instead, similar to the other branch in `reify_has_one`.

The remaining breakage was due to the `Song` model relying on internals
that have changed from underneath it. From Rails 5 onwards there is a
public API available to do what it wants, so we can just use that
instead.

This commit is not expected to pass on Rails 3, as #898 makes it sound
like support might be dropped. If this needs to be ammended to support
Rails 3, I will do so, but I will also grumble very loudly about it.
I had removed the second argument since I made it optional upstream, but
in Rails 5 it's still mandatory.
EOL software woo!
@jaredbeck jaredbeck merged commit 29ec1c9 into master Dec 3, 2016
@jaredbeck jaredbeck deleted the thanks_sean_rails-5.1 branch December 3, 2016 22:42
@jaredbeck
Copy link
Member Author

For posterity, this was a rebase of #899 which was first discussed in #892

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants