-
Notifications
You must be signed in to change notification settings - Fork 344
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
Collapse database migrations #3524
Conversation
a163858
to
537c744
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
What happens if someone is not on the latest minor version before migrating to this version? |
You should only have to run an upgrade once to get from any arbitrary minor version to the latest. Unless you mean trying to allow people to go from e.g. v1.x -> v4.x skipping everything in between? That's never been possible afaik. |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
just resolved the CHANGELOG.md conflict straight from GH |
traffic_ops/app/db/migrations/20190424165437_valid_latitudes_and_longitudes.sql
Outdated
Show resolved
Hide resolved
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.
there are a number of things that changed in addition to collapsing the migrations. This PR should be limited to only creating the db as if it had gone through the migrations and nothing more.
Any other fixes to tables or data should be addressed in a separate PR. The extra constraint migration should be alone in a separate PR.
Traffic Ops will fail to install without any migrations - any change that collapses migrations must also do one of:
|
ae8674d
to
d7c95a3
Compare
Instead of introducing a new migration, this now merely leaves in the migrations introduced since the release of 3.0.x as the only remaining migrations after collapse. |
f91a8bd
to
45398a9
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
45398a9
to
9074696
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
0eefb3a
to
28ea824
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
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.
Realized that I hadn't run the patch
step on previous one, so some diffs I noted before are no longer there.
Couple of things still different that should be fixed.. Still want to run some more data thru it..
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.
still have the last_edited_by
error and conflict in CHANGELOG.md
that need to be addressed.
Ordinarilly this shouldn't matter - enums are meant to be opaque values, but we re-model these enums occasionally in client code.
Also add/removed some missing/incorrect NOT NULL etc. stuff
e62662b
to
24b1f8c
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
What does this PR (Pull Request) do?
Collapses all previous migrations into
seeds.sql
and/orcreate_tables.sql
(as appropriate). It does leave all migrations written since 3.0.x was released.Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
Building CDN-in-a-Box seems appropriate. That's what I did. Also, try dumping an older schema and comparing it with this. The only (real) difference should be the new latitude/longitude constraints.
If this is a bug fix, what versions of Traffic Ops are affected?
This isn't a bug fix, but on the topic of TO versions: this is a breaking change to the database, meaning rollbacks to migrations that previously existed will no longer be possible.
The following criteria are ALL met by this PR