-
-
Notifications
You must be signed in to change notification settings - Fork 727
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
Rails 5 upgrade #6635
Rails 5 upgrade #6635
Conversation
8152a0c
to
8309b97
Compare
e4bef0a
to
c725d4e
Compare
c782c0b
to
6f6518c
Compare
nice, 76 broken specs. Looks like a lot of small different issues. What's your perception of complexity of this one Matt? |
I think it's pretty close. 76 out of 4282 so... 1.8% failing? I think some of the tricky bits are around modifying the params in weird ways. They've made it much harder to do (to discourage it), but there's a few places where we really mess with the params object a lot. The other bit is the way we use collections and the ModelSet classes for bulk updates. The places where we deviate from Rails conventions and have made some messy code is the stuff that's that failing. I think by the time the build is green we will have to have tidied up the codebase quite a bit (which is actually a good thing). |
I just fixed another 12 or so errors over morning coffee, we should be at around ~64 remaining. |
|
||
private | ||
|
||
def raw_params |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this abstraction makes it very easy to move easily to master on dual boot:
def raw_params
if ENV['DEPENDENCIES_NEXT']=1
@raw_params ||= params.to_unsafe_h
else
params
end
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This raw_params
thing was a bit of a rough experiment, I assumed this would be cleaned up later. I'm not even sure this fix is the way to go...? 🤷♂️
It's a tricky one. The new object returned by params
behaves totally differently in Rails 5.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I think the pattern of having a service or concern to handle it as an adapter is a good one 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a simple problem. In places where we use strong params in a fairly simple way, everything works as before ✔️
In places where we try to modify the params in any way or expect it to behave like a hash, everything is broken ❌
For example we might try to delete a params key in a before_filter
callback for permissions reasons like:
params.delete(:order_id) unless has_permission?
Nope. ❌
😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is looking great! Only 24 broken specs 🎉
If you make a PR with all the calls to raw_params and use that if statement I put above. That will make this rails 5 PR surprisingly small! Awesome news!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only 14 left!
611a7b2
to
4719b26
Compare
25d74c4
to
5de711e
Compare
The erb tags in this partial were not being parsed as erb, breaking various other things on the page.
This was triggering an error via the callback Spree::Product#remove_previous_primary_taxon_from_taxons
It's not working at all in Rails 5. There's new concurrency modules in Rails 5, we should investigate them...
Turns out it works with Rails 5
3528c1e
to
bf35f6a
Compare
This can be closed now, right @Matt-Yorkley? |
WIP quick test of the build...