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
Reversible commands #8267
Reversible commands #8267
Conversation
Already out of date somehow :/ |
I've removed the entry in the Changelog (which was only for the #7627 anyways) When there's a decision about these 3 PRs, I'll add an entry in the Changelog. |
def remove_column(table_name, *column_names) | ||
columns_for_remove(table_name, *column_names).each {|column_name| execute "ALTER TABLE #{quote_table_name(table_name)} DROP #{column_name}" } | ||
def remove_columns(table_name, *column_names) | ||
raise ArgumentError.new("You must specify at least one column name. Example: remove_column(:people, :first_name)") if column_names.empty? |
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.
Should not be remove_columns
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.
Good eye
I've updated this PR with these additional changes:
|
@marcandre can you squash the commits, and I'll merge this in? |
@tenderlove Which commits should I merge? They should all stand by themselves, and many are not related at all to others |
@marcandre we generally squash all commits so that it's easy to backport/revert. |
@steveklabnik @tenderlove With all due respect, this is a terrible rationale. Not only is backporting/reverting rare, but Squashing is lossy, the commits I'm submitting are atomic and make it easier to understand what's going on, for example if anyone does a git blame at some point. Finally, if you decide to revert part of this (e.g. make drop_table revertible), you won't be able to if the commits are squashed. Similarly, the first commits are simple code improvements made because I noticed things while doing my changes. These commits total over 1000 line changes in total, I don't see a problem in them being split in a bunch of atomic commits. If you want me to open 13 different pull requests, I will, or maybe the commit messages should refer to this PR, but I won't squash these commits. Of course, you guys are free to do it yourself if you feel that's the way it should be. |
…olumn reversible. [rails#8267]
Updated commit logs with this PR number (except the first three which aren't directly related). Had forgotten to update the ChangeLog, so this PR will probably conflict soon. |
I'm getting these errors when running with mysql2:
(there are a bunch of apparently related errors and travis build page for mysql/mysql2 doesn't seem to be loading) Also, travis reported a failing test in railties. And another fix I already commited in 68e91da...4da76d7. @marcandre would you mind taking a look at the mysql failures? I think I'll just be able to continue working on it tomorrow, so if you can, that'd be very welcome. Thanks. |
@carlosantoniodasilva Thanks for the fixes. The railties error is trivial (string vs symbol), but I'm not sure what's up with the mysql errors. Probably related to using transaction in the migration? I'll be able to check that first thing tomorrow. |
@marcandre it seems so, somehow related to the |
@carlosantoniodasilva Right. I still can't imagine why it causes a problem on mysql, but I'll just not use transaction at all. Actually I can probably use send something |
@marcandre thanks, let me know if you find anything or need any help. |
This PR broke the build: https://travis-ci.org/rails/rails/jobs/3781822 |
* Fix Migration#reversible by not using `transaction`. * Adapt mysql adapter to updated api for remove_column * Update test after aedcd68
@josevalim Should all be fixed by [#8588] |
`def remove_columns(table_name, *column_names)` is defined in ActiveRecord::ConnectionAdapters::SchemaStatements, which does not require Oracle enhanced specific implementation. `def remove_column(table_name, column_name, type = nil, options = {})` ignores `type` and `options` arguments to avoid ORA-00904 errors See rails/rails#8267 for Rails change. This commit should not backport into release14 branch.
def change
remove_index :users, column: :email
end But when providing the column in the normal way, def change
remove_index :users, :email
end you get this error message:
Is this by design, or should I create a ticket / PR for it? |
@seanlinsley Definitely not by design! Issue or PR would be good (I don't have time now), please cc me though |
This pull request makes the following commands reversible:
It also creates the reversible command
drop_join_table
.Finally,
remove_columns
andremove_column
are no longer aliases and the interface ofremove_column
is changed to accept only one column (along with new arguments that are used in case of reversal).The PR builds on #8177 (itself building on #7627), but the need they all fulfill is independent. Each PR can be accepted/rejected independently. I hope all three can be accepted as they nicely complement each other and give powerful means to create reversible migrations. The ChangeLog remains to be updated, but I'll wait until confirmation that this will be merged.
Thanks