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

Object locking in Flyway Desktop

One for the Redgate team:

The product "SQL Source Control" includes a very handy tool that enables the locking of database objects, preventing accidental changes. This is particularly useful in the case of a shared development database.

I note that the roadmap for Flyway (see here) makes no specific mention of integrating this feature in the future. Currently, there is a requirement to install SQL Source Control as a separate application in order to benefit from object locking.

Will this feature be integrated into Flyway Desktop at some point?
JR_AUS
0

Comments

5 comments

  • Peter_Laws
    Hello JR_AUS, thanks for the question.

    Probably not in the near future, as you can see here, the prefered and encouraged dev configuration is dedicated so it's less of a priority than in the SQL Source Control context.
    Peter_Laws
    0
  • JR_AUS
    Peter_Laws said:
    Hello JR_AUS, thanks for the question.

    ...the prefered and encouraged dev configuration is dedicated...
    Thanks Peter, understood. The reality, of course, is that, for various reasons, dedicated development environments aren't always possible or desirable (we know there are pros and cons to shared and dedicated). In fact, we have met some difficulties in setting up Flyway in our enterprise environment because it has a bent toward dedicated developer databases.

    Our team is following the current recommended advice for a shared environment from the link you provided, which is:
    Recommendations if you must use a shared development database environment
    If you are unable to provision dedicated development environments, for example using Flyway Enterprise's cloning capabilityFlyway Desktop can be used with a shared development database.  
    Please note that: 
    • We recommend that you leave the Repeatable Migrations feature disabled in the project if you utilize any form of branching in your version control system

    Many thanks for you response.
    JR_AUS
    0
  • JR_AUS
    Peter_Laws said:
    Hello JR_AUS, thanks for the question.

    ...the prefered and encouraged dev configuration is dedicated...
    Thanks Peter, understood. The reality, of course, is that, for various reasons, dedicated development environments aren't always possible or desirable (we know there are pros and cons to shared and dedicated). In fact, we have met some difficulties in setting up Flyway in our enterprise environment because it has a bent toward dedicated developer databases.

    Our team is following the current recommended advice for a shared environment from the link you provided, which is:
    Recommendations if you must use a shared development database environment
    If you are unable to provision dedicated development environments, for example using Flyway Enterprise's cloning capabilityFlyway Desktop can be used with a shared development database.  
    Please note that: 
    • We recommend that you leave the Repeatable Migrations feature disabled in the project if you utilize any form of branching in your version control system

    Many thanks for you response.
    JR_AUS
    0
  • StephanieHerr
    You can continue to use SQL Source Control for Object Locking while tracking your database changes and generating migrations for deployment with Flyway.  If you'd like to see this directly in Flyway, please add a suggestion to our UserVoice site - https://redgate.uservoice.com/forums/949477-flyway.
    StephanieHerr
    0
  • JR_AUS
    You can continue to use SQL Source Control for Object Locking while tracking your database changes and generating migrations for deployment with Flyway.  If you'd like to see this directly in Flyway, please add a suggestion to our UserVoice site - https://redgate.uservoice.com/forums/949477-flyway.
    Thank you, Stephanie.

    We have decided to use SQL Source Control exclusively, as Flyway does not handle our many cross-database dependencies very well.
    JR_AUS
    0

Add comment

Please sign in to leave a comment.