-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Refactor sync metadata to handle index creation if already exists #12757
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
Conversation
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.
PR Summary
Implements a temporary fix for index creation during version 55 to 56 migration by catching and logging index errors instead of throwing them. This change affects the workspace migration process but raises concerns about the implementation approach.
- Added hardcoded boolean
isv55tov56
inworkspace-migration-runner.service.ts
to handle index creation errors, which violates clean code principles - Using hardcoded version checks (
v55tov56
) instead of proper migration versioning raises maintainability concerns - This temporary solution bypasses proper error handling, potentially masking critical issues
- Consider implementing a more robust versioning mechanism for handling pre-existing indexes
1 file reviewed, no comments
Edit PR Review Bot Settings | Greptile
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.
ideally, we should check the workspace version to avoid this temp code. But i don't think we have access to this info here
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.
@@ -226,7 +226,16 @@ export class WorkspaceMigrationRunnerService { | |||
if (error.code === '42P07') { | |||
return; | |||
} | |||
throw error; | |||
|
|||
const isv55tov56 = true; |
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.
NItpick: We could be checking APP_VERSION value directly ( ps: we're releasing 0.60 )
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.
we should check the error messageFormat instead, it's not important to check the version IMO, + Add a // TODO
🚀 Preview Environment Ready! Your preview environment is available at: http://bore.pub:12436 This environment will automatically shut down when the PR is closed or after 5 hours. |
@@ -226,7 +226,14 @@ export class WorkspaceMigrationRunnerService { | |||
if (error.code === '42P07') { | |||
return; | |||
} | |||
throw error; | |||
// TODO: Remove this once we have re-indexed all our relations | |||
if (error.message.includes('already exists')) { |
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 should also check for Index :p
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.
that's being said we are in the create index function
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.
LGTM :p
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.
Let's double check the functional behavior:
- workspace with indexMetadata + IDX in db
- workspace without indexMetadata and without index in db
- workspace without indexMetadata but already index in db
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.
- first one checked locally
doing the other ones currently
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.
does not seem to fix locally the issue. investigating
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.
Note: Also very important to test on mulitple index for one objectmetadata to trigger the transaction failure
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.
locally:
✅ workspace with indexMetadata + IDX in db
✅ workspace without indexMetadata and without index in db
✅ workspace without indexMetadata but already index in db
const whereClause = index.where ? `WHERE ${index.where}` : ''; | ||
|
||
await queryRunner.query(` | ||
CREATE ${isUnique} INDEX IF NOT EXISTS "${index.name}" ON "${schemaName}"."${tableName}" (${quotedColumns.join(', ')}) ${whereClause} |
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.
Nitpick: Would still escape params here
@greptileai trigger |
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.
PR Summary
Refactored index creation logic to use raw SQL queries with 'IF NOT EXISTS' clause instead of TypeORM's TableIndex, providing a more permanent solution for handling pre-existing indexes during migrations.
- Removed direct TypeORM TableIndex usage in favor of raw SQL queries, improving flexibility and control over index creation
- Implemented 'IF NOT EXISTS' clause for index creation to prevent failures with pre-existing indexes
- Consider extracting SQL queries into a dedicated database utility service for better maintainability
- Ensure consistent error logging and monitoring for index creation operations
- Consider adding integration tests specifically for index recreation scenarios
1 file reviewed, no comments
Edit PR Review Bot Settings | Greptile
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.
Lgtm + @prastoin comment
In order to put back relations on track, we need to allow the preexisting indexes to be created in indexmetadata, but also to avoid failure when the migration runner will try to re-apply a pre-existing index
In order to put back relations on track, we need to allow the preexisting indexes to be created in indexmetadata, but also to avoid failure when the migration runner will try to re-apply a pre-existing index
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
Coco is faster than you |
In order to put back relations on track, we need to allow the preexisting indexes to be created in indexmetadata, but also to avoid failure when the migration runner will try to re-apply a pre-existing index