Allow base for Table
schema definition to be injected into #change_table
#45669
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR is a part of the work to allow users to customize migration behaviour by swapping in their own migration execution strategy objects, which can be used to perform schema statement methods. (See #45324 for more context).
#change_table
(when not used in bulk alter query mode) operates by building aTable
schema definition, and then yielding that object to the#change_table
block. Any methods called within the block are sent to theTable
object, which then forwards them to@base
. For example,#column
:rails/activerecord/lib/active_record/connection_adapters/abstract/schema_definitions.rb
Lines 677 to 684 in ab325a9
simply sends the
#add_column
message to@base
, which is the connection adapter.If apps are using a custom migration execution strategy and defining methods such as
#add_column
,#add_index
, etc., they probably don't want#change_table
to send commands to the connection adapter. Instead, it makes more sense that these methods would go to their strategy object. As such, I'm proposing that we simply allowbase
to be passed as an optional argument to#change_table
, with theTable
definition constructed using the supplied base. A custom strategy could then do something like this: