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
Do not use Arel.star
when ignored_columns
#30980
Do not use Arel.star
when ignored_columns
#30980
Conversation
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review. Please see the contribution instructions for more information. |
e956302
to
f8bd7e1
Compare
Let me know when the tests are green |
ab9fd5b
to
fe42e50
Compare
@rafaelfranca the failures aren't related to this change anymore (not sure why they are happening at all now, maybe an intermittent failure). I'm not sure if this is going to the right direction, can you please review the test changes and confirm this is the way to go? |
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.
Changes looks good to me. Only one question. Restarted the jobs to see if they now pass.
@@ -118,76 +118,76 @@ def test_unscope_after_reordering_and_combining | |||
end | |||
|
|||
def test_unscope_with_where_attributes | |||
expected = Developer.order("salary DESC").collect(&:name) | |||
received = DeveloperOrderedBySalary.where(name: "David").unscope(where: :name).collect(&:name) | |||
expected = Developer.order("salary DESC").order(:name).collect(&:name) |
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.
Do you remember why we need to add a new order here?
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.
The build was resulting in a different order between expected and received, I normalized both by using a predictable order.
Not sure why it started to fail in this PR but I have assumed that Postgres changed the order of the results for some reason (there is no guarantee in the order of the results in Postgres unless specified, in that case, if the salary is the same we do not have a guaranteed order of the records [there is but it is the order of the record on the disk that may vary from time to time]).
In the other hand, I'm not sure if this is the real problem but since this PR change should not impact on this test at all I assumed it was that.
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.
might be better to do assert_equal(expected.sort, received.sort)
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.
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.
Pretty much the same, should I change it to sort in ruby instead of the database?
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.
I prefer to because of the already existing order
that we have on those tests
@rafaelfranca the build is green now 🤘 |
assert_match %(EXPLAIN for: SELECT `developers`.* FROM `developers` WHERE `developers`.`id` = 1), explain | ||
assert_match %r(developers |.* const), explain | ||
explain = Author.where(id: 1).explain | ||
assert_match %(EXPLAIN for: SELECT `authors`.* FROM `authors` WHERE `authors`.`id` = 1), explain |
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.
Why are you changing mysql2's tests only from Developer to Author?
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.
The original author wanted to keep the EXPLAIN with the STAR and for that, the model had to be changed.
I can update the EXPLAIN test to keep the Developer model and update the regexp to match against the new query.
What do you think?
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.
I think it is better to fix all other explain tests to use Author to not have a fragile test that will have to change every time the list of ignored column at Developers change.
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.
I'm thinking of creating a specific model for that feature, in that way the model will be exclusive for that feature and won't break anything around that.
Or even use something like that:
test '...' do
begin
Developer.ignored_columns = [:first_name, :last_name]
assertions here
ensure
Developer.ignored_columns = []
end
end
What do you think?
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.
I think changing to author is a good solution already that doesn't require adding any new code.
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.
So change the other specs to use author too?
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.
Yeah 👍
assert_equal 1, scope.where_clause.ast.children.length | ||
assert_equal Developer.where(name: "David"), scope | ||
assert_equal DeveloperCalledJamis.where("salary < 10000").to_a, scope.to_a |
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.
Is this change necessary?
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.
I have no idea, I left as the original author wrote, I will try to revert that and see what happen.
@rafaelfranca can you take a look again? |
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.
👍 Can you squash your commits?
@rafaelfranca like this? |
ab25bad
to
736cbea
Compare
This works, but you could at least three commits in your PR because they were atomic. |
If there are any ignored columns, we will now list out all columns we want to be returned from the database. Includes a regression test.
736cbea
to
f8627df
Compare
@rafaelfranca done! |
Thanks! I'll merge in a minute |
…lumns Do not use `Arel.star` when `ignored_columns`
- rails#30980 introcuded a change to not use `Arel.star` when model have ignored columns, a query used to look like `SELECT *. FROM developers` whereas now it would like `SELECT column1, column2 FROM developers` - If a column has the same name has a reserved database specific keyword (such as key, where ...) then the query would fail because the names aren't quoted - Quoting almost always happen unless we use a `from` clause in the query https://github.com/rails/rails/blob/9965b98dc0d58a86e10b4343bb6e15e01661a8c3/activerecord/lib/active_record/relation/query_methods.rb#L1052 - This PR cast all columns name to symbols in order for the quoting logic to be picked up https://github.com/rails/rails/blob/9965b98dc0d58a86e10b4343bb6e15e01661a8c3/activerecord/lib/active_record/relation/query_methods.rb#L1054-L1055 - A reproduction script can be found here https://gist.github.com/Edouard-chin/f56d464a0adcb76962afc1a9134a1536
Closes #27918
Closes #27914