AutoMigrate: Rename/Create/Drop tables #926
Open
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.
This PR is my second attempt at implementing #456 :)
This time around I decided to start with the functionality we want to bring (
AutoMigrator
), design a good interface and work from there.I took into account our discussions of the ALTER TABLE functionality from #726 and let each dialect export a simple
RenameTable(context.Context, string, string)
function to be used byAutoMigrator
's internals. My thinking was that, if auto migration is done well, the users wouldn't need to work with ALTER TABLE all that much.❕
AutoMigrator.Migrate()
is just a sketch -- running it will do the migration and record it in the db, but the users won't be able to revert it because no migration file (.sql or .go) is generated at the moment.AutoMigrator.Run()
should be used to run the migrations "in-place".There might be other improvements to make here (e.g. add more unit test cases) but I thought I'd put it out here sooner to get the feedback.
What is still to do:
type:
)Other:
test.sh
to pass additional arguments togo test
(for example, now possible to run 1 test with
./test.sh -run=TestAutoMigrator_Run
)