Come up with a migration system for DB schema #111
Milestone
Comments
Closed
|
Changing this from enhancement to question, as we're going to use an existing tool and the only question is which one. |
|
Moving to General Availability. We can get through audit / first issuance with things as they are. |
|
This is blocking #623, so we're doing this for Deployment now. |
jmhodges
added a commit
that referenced
this issue
Aug 21, 2015
This has required some substantive changes to the tests. Where previously the foreign key constraints did not exist in the tests, now that we use the actual production schema, they do. This has mostly led to having to create real Registrations in the sa, ca, and ra tests. Long term, it would be nice to fake this out better instead of needing a real sa in the ca and ra tests. The "goose" being referred to is <https://bitbucket.org/liamstask/goose>. Database migrations are stored in a _db directory inside the relevant owner service (namely, ca/_db, and sa/_db, today). An example of migrating up with goose: goose -path ./sa/_db -env test up An example of creating a new migration with goose: goose -path ./sa/_db -env test create NameOfNewMigration sql Notice the "sql" at the end. It would be easier for us to manage sql migrations. I would like us to stick to only them. In case we do use Go migrations in the future, the underscore at the beginning of "_db" will at least prevent build errors when using "..." with goose-created Go files. Goose-created Go migrations do not compile with the go tool but only with goose. Fixes #111 Unblocks #623
jmhodges
added a commit
that referenced
this issue
Aug 22, 2015
This has required some substantive changes to the tests. Where previously the foreign key constraints did not exist in the tests, now that we use the actual production schema, they do. This has mostly led to having to create real Registrations in the sa, ca, and ra tests. Long term, it would be nice to fake this out better instead of needing a real sa in the ca and ra tests. The "goose" being referred to is <https://bitbucket.org/liamstask/goose>. Database migrations are stored in a _db directory inside the relevant owner service (namely, ca/_db, and sa/_db, today). An example of migrating up with goose: goose -path ./sa/_db -env test up An example of creating a new migration with goose: goose -path ./sa/_db -env test create NameOfNewMigration sql Notice the "sql" at the end. It would be easier for us to manage sql migrations. I would like us to stick to only them. In case we do use Go migrations in the future, the underscore at the beginning of "_db" will at least prevent build errors when using "..." with goose-created Go files. Goose-created Go migrations do not compile with the go tool but only with goose. Fixes #111 Unblocks #623
jmhodges
added a commit
that referenced
this issue
Aug 22, 2015
This has required some substantive changes to the tests. Where previously the foreign key constraints did not exist in the tests, now that we use the actual production schema, they do. This has mostly led to having to create real Registrations in the sa, ca, and ra tests. Long term, it would be nice to fake this out better instead of needing a real sa in the ca and ra tests. The "goose" being referred to is <https://bitbucket.org/liamstask/goose>. Database migrations are stored in a _db directory inside the relevant owner service (namely, ca/_db, and sa/_db, today). An example of migrating up with goose: goose -path ./sa/_db -env test up An example of creating a new migration with goose: goose -path ./sa/_db -env test create NameOfNewMigration sql Notice the "sql" at the end. It would be easier for us to manage sql migrations. I would like us to stick to only them. In case we do use Go migrations in the future, the underscore at the beginning of "_db" will at least prevent build errors when using "..." with goose-created Go files. Goose-created Go migrations do not compile with the go tool but only with goose. Fixes #111 Unblocks #623
jmhodges
added a commit
that referenced
this issue
Aug 25, 2015
This has required some substantive changes to the tests. Where previously the foreign key constraints did not exist in the tests, now that we use the actual production schema, they do. This has mostly led to having to create real Registrations in the sa, ca, and ra tests. Long term, it would be nice to fake this out better instead of needing a real sa in the ca and ra tests. The "goose" being referred to is <https://bitbucket.org/liamstask/goose>. Database migrations are stored in a _db directory inside the relevant owner service (namely, ca/_db, and sa/_db, today). An example of migrating up with goose: goose -path ./sa/_db -env test up An example of creating a new migration with goose: goose -path ./sa/_db -env test create NameOfNewMigration sql Notice the "sql" at the end. It would be easier for us to manage sql migrations. I would like us to stick to only them. In case we do use Go migrations in the future, the underscore at the beginning of "_db" will at least prevent build errors when using "..." with goose-created Go files. Goose-created Go migrations do not compile with the go tool but only with goose. Fixes #111 Unblocks #623
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now we create the DB in memory fresh each time we run a test Boulder server, which means schema changes are trivial.
Eventually we will have a production database that we can't blow away. We should set up a system of migrations similar to those used in ORMs, so that when we make schema changes we can also define how to apply those changes to a running table. This should probably take the form of a series of date-stamped SQL files and a table that records which migrations have been run on a given DB.
The text was updated successfully, but these errors were encountered: