-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
[indexer-alt] - make migration optional #20803
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
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.
Beyond making Indexer::new
accept an optional migrations
, it looks like we'd just need to modify the function to not run db.run_migrations
, around L145
I'm not sure if we need to make the other modifications, for the ResetDatabase command, an app indexer should just provide the skip-migrations
flag
pub fn migrations( | ||
migrations: &'static EmbeddedMigrations, | ||
migrations: Option<&'static EmbeddedMigrations>, | ||
) -> impl MigrationSource<Pg> + Send + Sync + 'static { | ||
struct Migrations(&'static EmbeddedMigrations); | ||
struct Migrations(Option<&'static EmbeddedMigrations>); | ||
impl MigrationSource<Pg> for Migrations { | ||
fn migrations(&self) -> migration::Result<Vec<Box<dyn Migration<Pg>>>> { | ||
let mut migrations = MIGRATIONS.migrations()?; | ||
migrations.extend(self.0.migrations()?); | ||
if let Some(more_migrations) = self.0 { | ||
migrations.extend(more_migrations.migrations()?); | ||
} | ||
Ok(migrations) | ||
} | ||
} |
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.
seems like this can still be kept as non-optional. it's only called when the ResetDatabase command is invoked. There, an indexer that isn't responsible for managing db-schema would pass skip-migrations
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.
I think we do need this change, because we also call this function in Indexer::new
, and we want the indexer to be able to run migrations related to the indexing framework even if it is not responsible for the app-specific schema.
(!skip_migrations).then(|| Indexer::migrations(Some(&MIGRATIONS))), | ||
) |
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.
i think an app indexer would just provide the skip-migrations
flag
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.
IIUC, an app-specific indexer wouldn't be using this codebase (it would have its own binary).
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.
Looks reasonable to me, with the caveat that this set-up is inherently a little dicey (having multiple writers and one of them is responsible for maintaining the schema).
pub fn migrations( | ||
migrations: &'static EmbeddedMigrations, | ||
migrations: Option<&'static EmbeddedMigrations>, | ||
) -> impl MigrationSource<Pg> + Send + Sync + 'static { | ||
struct Migrations(&'static EmbeddedMigrations); | ||
struct Migrations(Option<&'static EmbeddedMigrations>); | ||
impl MigrationSource<Pg> for Migrations { | ||
fn migrations(&self) -> migration::Result<Vec<Box<dyn Migration<Pg>>>> { | ||
let mut migrations = MIGRATIONS.migrations()?; | ||
migrations.extend(self.0.migrations()?); | ||
if let Some(more_migrations) = self.0 { | ||
migrations.extend(more_migrations.migrations()?); | ||
} | ||
Ok(migrations) | ||
} | ||
} |
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.
I think we do need this change, because we also call this function in Indexer::new
, and we want the indexer to be able to run migrations related to the indexing framework even if it is not responsible for the app-specific schema.
(!skip_migrations).then(|| Indexer::migrations(Some(&MIGRATIONS))), | ||
) |
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.
IIUC, an app-specific indexer wouldn't be using this codebase (it would have its own binary).
a2261e8
to
de66d05
Compare
Description
Apps indexer might not be managing the DB schema, making migration optional to cater that use case.
Test plan
How did you test the new or updated feature?
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.