How can we help you today? How can we help you today?
Hassan Imam

Activity overview

Latest activity by Hassan Imam

Hey Rakesh, When you baseline a database, Flyway creates an entry in the schema history table marking that point as your starting baseline. However, repeatable migrations (R__ files) have different behavior than versioned migrations - they're designed to be applied whenever their checksum changes, regardless of baseline status. This is why all your R__ files are executing on the first migration run after baseline. Key Questions to Clarify: What is your baseline entry pointing to in the schema history table, and what version/state is it baselined to? Are you using Flyway Community or Teams/Enterprise edition? Recommended Solution: State-Based Approach (Flyway Teams/Enterprise) Since you mentioned tracking stored procedure changes while avoiding unnecessary re-execution, I highly recommend using Flyway's state-based migrations instead of file-based repeatable migrations. This approach perfectly addresses your requirements: Change detection: Only applies changes when there are actual differences between your desired state and current database state No unnecessary execution: Won't re-run DDL for objects that haven't changed Change tracking: Provides the exact change-tracking behavior you need for stored procedures / comments
Hey Rakesh,When you baseline a database, Flyway creates an entry in the schema history table marking that point as your starting baseline. However, repeatable migrations (R__ files) have different ...
0 votes