How can we help you today? How can we help you today?

Need to baseline the database with R__ migration scripts before first migration

Hello,


I have a database with 100 stored procedures. I am setting up flyway via Azure DevOps pipeline. I want to baseline the database before first migration. I have made R__ files for all the 100 stored procedures. which is uploaded to the repository. Now I want to baseline with all these 100 R__ files and the objects present in the database. it is done. flyway history table is created with one baseline entry and output shows baseline complete. But when I run migration for the first time, it applies all the R__ files. which I dont want to execute. These R__ files should be applied only if any changes are made to them.

please help me on how to achieve this?  do we have any way other than manually adding the R__ migration files entries to flyway history table.

reason that we dont want to execute R__ files on initial execution is that its a requirement to not modify, update or rerun the DDL of the objects.

Rakesh Kumar E N
1

Comments

1 comment

  • 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:

    1. What is your baseline entry pointing to in the schema history table, and what version/state is it baselined to?
    2. 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
    Hassan Imam
    0

Add comment

Please sign in to leave a comment.