sql - How to Version Control The Baseline Of DB Schema in Liquibase -


i evaluate how organisation make use of liquibase db versioning system.

however, have difficulties on how liquibase philosophy fits our current workflow:

currently have create , initial fill sql scripts of our application under version control. there change (e.g. new column) programmer adjusts create script , checks changes in. since application code , sql scripts in same repository db objects should in sync application version.

additionally, each release maintain list of alter... statements used when customer upgrades our software (which more case installing scratch).

so have 2 worlds - current version of schema objects create statements in repository plus list of necessary actions version 1 2 (alter statements).

what definition of schema objects matches version of software since in same version control repository.

what don't (and hence looking alternative) double work have do. furthermore, since software more updated newly installed, create statements more of documentation applied database.

what understood is, liquibase starts baseline , operating on small change sets. once check in base line , add small change sets.

over time might have old baseline lots of change sets. assume have manually generate new baseline out of old baseline + changesets , start there again. sounds rather confusing me. i'm not sure if co-workers see benefits compared our current workflow.

what recommend?

this opinion, take such.

the liquibase philosophy baselines mention not needed, long database can queried see changes have been applied it, assumption have periodically generate new baseline incorrect.

let's compare how process works vs. liquibase process.

  • in current system, said, developers have maintain 2 sets of sql scripts , testers have ensure correct. when users install, installer has detect whether clean install , run 'create' scripts. when installer detects upgrade, has take different path (possibly using complex logic) determine of alter scripts run. organization has maintain installer code upgrade logic.

  • using liquibase, developers create 'alter' part of database scripts. new install, might take fractionally longer run liquibase statements take run create scripts in current system, benefit reduced duplication , therefore reduced bugs. upgrade installs, liquibase determines looking @ installed database changes in place , runs changes necessary bring database date code being installed.


Comments

Popular posts from this blog

commonjs - How to write a typescript definition file for a node module that exports a function? -

openid - Okta: Failed to get authorization code through API call -

thorough guide for profiling racket code -