Support for triggers no rollback#30
Conversation
shlomi-noach
left a comment
There was a problem hiding this comment.
Thank you for this work! I am told this already runs well in your production environment?
I do have a few comments on both logic and coding style, see inline.
One thing I'm confuse about is the rollback: Incase there is a rollback and the ghost table is either not in use or dropped, then why do we need to do any rollback on the ghost triggers?
I'm assuming by "rollback on the ghost triggers" you mean "dorpping" them. And right now I don't find a good case why we'd have to drop them.
|
I've made all the necessary changes. |
shlomi-noach
left a comment
There was a problem hiding this comment.
Other than minor comment, and pending further production testing, this looks good to me!
|
CI fails on |
Support for triggers
|
Done! |
|
Please see unit tests failure: |
change trigger suffix logic
Sorry about that. Forgot to add the test file to the PR. I've added back the br, |
|
Pushed a |
|
Past due time, this now merged! Great work everyone and congrats! |
|
@shlomi-noach i see that this change not in https://github.com/github/gh-ost |
* Add trigger support to gh-ost based on openark#30 * Add comprehensive test cases for trigger support functionality * Fix trigger-basic test by adding required --trigger-suffix parameter and remove fail-trigger-unsupported test * Update trigger suffix in local test configurations Modify extra_args files for trigger-complex, trigger-multiple, and trigger-self-reference tests to use different trigger suffixes * Add --remove-trigger-suffix-if-exists to local test configurations Update extra_args files for trigger tests to include the new --remove-trigger-suffix-if-exists option, ensuring consistent trigger handling across different test scenarios * Fix trigger-long-name test by reducing trigger name length to be valid * Standardize trigger drop statements in local test configurations Update create.sql files across trigger test scenarios to: - Consistently drop both original and ghost triggers - Ensure clean slate before creating triggers - Align with recent trigger suffix changes This change improves test reliability and consistency by explicitly dropping all potential trigger variations before test setup. * Consolidate and enhance trigger test configurations Refactor local test scenarios for triggers by: - Merging multiple trigger test configurations into comprehensive test cases - Updating create.sql files with more complex and diverse trigger scenarios - Standardizing trigger and table setup across different test configurations - Removing redundant test directories while preserving test coverage This change simplifies the trigger testing infrastructure and provides more robust test coverage for gh-ost's trigger handling capabilities. * Add debug logging for ghost trigger validation process Enhance ghost trigger existence check by adding detailed debug logging to: - Log the ghost trigger name being searched - Log the database schema and query details - Log when an existing ghost trigger is found This change improves visibility into the trigger validation process, making troubleshooting easier during migration scenarios. * Improve ghost trigger validation with enhanced logging and verification Modify validateGhostTriggersDontExist() to: - Add a direct query to log all triggers in the database schema - Refactor trigger existence check to use count-based query - Improve debug logging for trigger validation process - Provide more detailed error reporting for existing ghost triggers This change enhances the robustness and observability of the trigger validation mechanism in gh-ost's migration process. * Refactor ghost trigger validation to improve logging and error detection Simplify and enhance the validateGhostTriggersDontExist() method by: - Removing redundant direct query logging - Streamlining trigger existence check - Improving debug logging for trigger validation - Consolidating trigger existence detection logic The changes provide more concise and focused trigger validation with clearer error reporting. * Simplify ghost trigger validation query and reduce logging verbosity Refactor validateGhostTriggersDontExist() to: - Streamline trigger existence check query - Remove redundant debug logging statements - Use a more concise approach to detecting existing triggers The changes reduce code complexity while maintaining the core validation logic for ghost triggers. * Enhance ghost trigger validation query to include table name filter Modify validateGhostTriggersDontExist() to: - Add table name filter to trigger existence check query - Improve specificity of ghost trigger detection - Prevent false positives from similarly named triggers in different tables The change ensures more precise ghost trigger validation by incorporating the original table name into the query criteria. * Enhance trigger test configuration with advanced features and consolidated test scenarios Update trigger-advanced-features test configuration to: - Add new column 'color' and 'modified_count' to test table - Implement more complex trigger logic for color and count tracking - Consolidate trigger test scenarios with richer data transformations - Modify event to test both numeric and color-based updates - Remove redundant trigger-basic-features directory The changes provide a more comprehensive and nuanced test suite for gh-ost's trigger handling capabilities, demonstrating advanced trigger behaviors and self-referencing updates. * Fix lint errors * Update trigger test configuration with suffix change Modify the extra_args file to use '_ght' trigger suffix instead of '_gho', maintaining consistency with recent trigger test configuration updates. * Remove gh-ost-ci-env submodule Clean up repository by removing the gh-ost-ci-env submodule, which appears to be no longer needed in the project structure. * Update create.sql --------- Co-authored-by: Yakir Gibraltar <yakir.g@taboola.com>
Hi @shlomi-noach ,
Here is a working version of trigger support.
3 new flag added:
As agreed, we create a ghost trigger instead of a complete trigger migration.
One thing I'm confuse about is the rollback: Incase there is a rollback and the ghost table is either not in use or dropped, then why do we need to do any rollback on the ghost triggers?