Repository navigation
Conversation
Sets up the Postgres side of the subscription store: settings for the app and migrations URLs, a pgbouncer-safe engine, the subscriptions table, and a migrate command. The devserver and CI get a local Postgres.
This branch has not been deployed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
resolves INFRENG-678
Adds a Postgres connection and alembic migrations for the subscription store, with a first migration creating the
subscriptionstable and asnuba subscriptions-postgres migratecommand to run it. Nothing reads or writes the table yet; that comes with the store itself in INFRENG-679.I put the migrations in
snuba/subscriptions/postgres/migrations/, next to the code that'll use them, and they run on plain alembic. They have nothing to do with snuba's ClickHouse migration system: there's no group to register, andsnuba migrationsnever sees them. I did consider putting them undersnuba/snuba_migrations/so all of snuba's migrations live in one place, but the tooling there assumes ClickHouse (check-migrations.pywould fail this PR for mixing migrations with other code, andddl-changes.pywould parse them as ClickHouse DDL). Keeping them with the feature is also how sentry does it with Django, where each app has its ownmigrations/folder. If you'd rather have everything in one place, I'm happy to move them.