This repository has been archived by the owner on Jun 28, 2018. It is now read-only.
use timestamp (to seconds precision) for versions #95
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Newer docker-composes (with newer YAML parsers) see the "yes" as a boolean type and reject it. So, make it a string explicitly.
Depends on mattes#94. That'll need to be reviewed and merged first. Using timestamps instead of an incrementing counter reduces the chances of conflicts and invalid migrations states after merging in another branch of code. Since people tend to work on orthogonal parts of the codebase, having to coordinate over incrementing an integer tends to cause merge issues late in the process of putting their code all together. Along the way, we have to handle the fact that the original MySQL and PostgreSQL tables for migration versions used 32-bit integers instead of 64-bit integers. We inspect the column types of their migration tables and upgrade them non-destructively to 64-integers at the same time we check that the migration table exists. The other databases seem to already have the correct table types. We also have to introduce a Clock interface for testing the new code well. A Clock is just a handy way to control for time in tests. Since we're constrained by the public API, the Clock instance is a global we swap out during tests. This is not ideal, but usable.
jmhodges
force-pushed
the
version_timestamp
branch
from
b6dbd7a
to
211eb85
Compare
|
(It'd probably be wise for me to point out that prior art for this exists in ActiveRecord migrations and other similar projects.) |
|
Duplicate of #58 ? |
|
Oh, hunh, didn't know that patch existed. If it picked up some of the stuff for backwards compatibility this patch has, it might be easier for folks to switch to. |
|
Well, it strictly would be easier. Would be nice for that to happen! |
Closed
|
Dup of #73 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Depends on #94. That'll need to be reviewed and merged first.
This is backwards compatible with the current incrementing mechanism and won't cause issues for teams with differing versions of migrate.
Using timestamps instead of an incrementing counter reduces the chances of conflicts and invalid migrations states after merging in another branch of code. Since people tend to work on orthogonal parts of the codebase, having to coordinate over incrementing an integer tends to cause merge issues late in the process of putting their code all together.
Along the way, we have to handle the fact that the original MySQL and PostgreSQL tables for migration versions used 32-bit integers instead of 64-bit integers. We inspect the column types of their migration tables and upgrade them non-destructively to 64-integers at the same time we check that the migration table exists. The other databases seem to already have the correct table types.
We also have to introduce a Clock interface for testing the new code well. A Clock is just a handy way to control for time in tests. Since we're constrained by the public API, the Clock instance is a global we swap out during tests. This is not ideal, but usable.