-
Notifications
You must be signed in to change notification settings - Fork 21.7k
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
Add validations for t.references/add_reference options #33347
Add validations for t.references/add_reference options #33347
Conversation
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (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. |
What if we have an external database adapter that support other options that are not |
@rafaelfranca Hmm, that's a good point. I guess they'd overwrite the |
a8d2dac
to
ccad1a8
Compare
That was the reason why we never added validations to those methods. Given those methods generates SQL and those SQL can be easily verified we thought that users testing their migrations were enough to make sure the options they are passing are the correct one. But at the same time we also added to |
I think we should preserve the old behaviour for migrations generated on previous Rails versions: |
@rafaelfranca Ah, I see. |
@eugeneius It makes sense that a lot of people run That said, I wonder about people who have these errors (misspelling options like unique or null in existing migrations) who don't realize it. Finding misspelled options in legacy code is what inspired me to create the issue in the first place. |
@eugeneius good point. @georgewambold can you change the PR to implement the old behavior in the compatibility class? |
@rafaelfranca Would I put it in the |
Yes |
ccad1a8
to
4295cbd
Compare
Hmm. Adding a reference ultimately calls I also think this suggests that the validation should apply to adding a column, rather than a reference. |
42db8b8
to
c250e54
Compare
@eugeneius That's a great point-- This expands the scope of the issue a bit, but I agree that as references are really just columns, we could kill a few birds with one stone and put the validation on column creation. I just pushed up an updated branch-- Let me know what you think. @rafaelfranca What are your thoughts on adding options validations to all column definitions? Also what does it mean for compatibility? |
c250e54
to
6b2711a
Compare
@@ -427,6 +427,8 @@ def new_column_definition(name, type, **options) # :nodoc: | |||
|
|||
private | |||
def create_column_definition(name, type, options) | |||
options.assert_valid_keys(:type, :force, :null, :default, :id, :precision, :scale, :array, :primary_key, :index, :polymorphic, :unique, :foreign_key, :limit, :first, :after) |
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.
Failing tests with :comment
, :collation
, and :auto_increment
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.
👍 Good call
I'd like to hear @rafaelfranca's opinion on the idea before giving feedback on the implementation, but I think the approach to compatibility should be the same: only apply the validation to new migrations by restoring the old behaviour in the |
This adds a validation on which options can be passed when adding a reference to a table. The valid options are: :type, :index, :polymorphic, :unique, :foreign_key and :limit. Any other key is invalid. For example, this would not raise an error before this commit, now it does: create_table :posts do |t| t.references :users, fake_option: true end
6b2711a
to
c8d37ea
Compare
I like this idea. I've ran into this before where I've added options that I thought a method had but didn't and ended up with an incomplete database setup. Feels like a much more realistic scenario to guard against than some future external adapter that would have new keys outside of the list (that could just be updated in a new PR to be included in the list). |
:after, :array, :as, :auto_increment, :charset, :collation, :comment, | ||
:default, :first, :force, :foreign_key, :id, :index, :limit, :null, | ||
:options, :polymorphic, :precision, :primary_key, :scale, :stored, | ||
:temporary, :type, :unique, :unsigned |
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.
A thought instead of hardcoding the list here: if these were defined on the adapter class (this here being the abstract adapter), then each database could have its own set of allowed options. (def SubclassAdapter.valid_keys; super + [:custom_option]
)
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
I'm going to work on this when I get a chance -- I think it's a worthwhile feature. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Still a WIP but I picked this up in #39659 |
This adds a validation on which options can be passed when adding a
reference to a table. The valid options are: :type, :index, :polymorphic,
:unique, :foreign_key and :limit. Any other key is invalid.
For example, this would not raise an error before this commit, now it does:
create_table :posts do |t|
t.references :users, fake_option: true
end
Summary
Provide a general description of the code changes in your pull
request... were there any bugs you had fixed? If so, mention them. If
these bugs have open GitHub issues, be sure to tag them here as well,
to keep the conversation linked together.
Other Information
If there's anything else that's important and relevant to your pull
request, mention that information here. This could include
benchmarks, or other information.
If you are updating any of the CHANGELOG files or are asked to update the
CHANGELOG files by reviewers, please add the CHANGELOG entry at the top of the file.
Finally, if your pull request affects documentation or any non-code
changes, guidelines for those changes are available
here
Thanks for contributing to Rails!