Managing Database Development With Label Entities
Learn how to introduce an enhanced analysis of your database, while lending a hand to automation, with the help of some handy labels.
Join the DZone community and get the full member experience.Join For Free
managing the different stages of database development can be challenging due to the many objects that are actively being created and altered, the ability to view the change history of multiple changes on a single object or at a schema level, and the need to be able to select a version to deploy or roll back to.
for this, dbmaestro has implemented the label entity. a ‘label’ is a point-in-time reference to a state of the schema, compounded of all the checked-in changes at that point in time.
this post will explain the label entity, as well as the different setups referring to labels, revisions and live. it will also demonstrate how to best utilize the label entities as a baseline.
as far as dbmaestro is concerned , there are several different stages in a database change cycle.
once a change has been compiled on the database, a new object has been created, or an object has been altered, that change becomes part of the “ live ” settings . this setting refers to any change that is present on the database and has been compiled. it acts as a distinction for dml commands on tables that have their “content management” enabled.
after the change is checked into dbmaestro or the new object is added, that change creates a new “ revision ” for the object. each revision is saved in the dbmaestro repository and it is possible to view the revision history of an object. you can also select any two revisions and compare the changes between them, or select a single revision and compare it to the live version.
applying a “ label ” on a database will create a point-in-time reference to the latest checked-in revision for all the objects under the dbmaestro source control management for that database.
let’s take the following example:
- create table table1 (i number).
- add table1 to source control.
- create table table2 (i number).
- apply label1.
- add table2 to source control.
- apply label2.
- check out table 1.
- alter table1 add (j number).
- check in table1.
- check out table 1.
- alter table1 add (k number).
- apply label3.
live includes: table1 (i number, j number, k number) and table2 (i number). this is because those are the changes that have been compiled to the database.
label1 includes: table1 (i number). this is due to the fact that even though table2 existed, it wasn’t part of the source control.
label2 includes: table1 (i number) and table2 (i number).
label3 includes: table1 (i number, j number) and table2 (i number). since the new column k wasn’t checked in, it wasn’t included in the label.
the latest revision for the database will include: table1 (i number, j number) and table2 (i number). this is the last checked-in revision for each object.
understanding the differences between the settings allows great flexibility in building the deployment scripts.
the baseline entity came to resolve a very problematic issue with the two-way compare. in most cases, comparing the source and target will highlight differences. however, it will also lack the knowledge of whether the change happened on the source or on the target, which usually results in the source overriding the target. but what happens when something was deliberately changed on the target? for starters, we need to know that this change happened and we also need to be able to preserve that change.
this is where the baseline comes into play, evolving the two-way compare to a three-way compare. this entails ensuring that the change detection not only works between the source and the target, but also to a third schema, which serves as an “anchor” for both the source and target. this 3rd schema is a “label,” depicted as the baseline for the impact analysis.
the baseline allows you to identify not only the differences between the source and the target, but also provides the crucial information of whether the change occurred on the source or on the target. it also is able to identify the cases of a configuration drift and conflict when the same object was changed both on the source and the target.
a baseline can be any label entity, however, usually the label will be chosen from the target. in many cases, a third schema can be set up as a static point to a version upload, and the label on that third schema can be used as well. this is a very common setup when the target isn’t managed.
let’s take the following example:
- we start with both prod and dev on version 1
- the development team developed version 2 on dev, while also uploading hotfixes to prod.
- if we were to deploy version 2.0 from dev to prod without a baseline, the following changes would have been performed:
however, if we were to do the same with prod 1.0 as a baseline, the outcome would be different:
- create table2. table2 appears in the source, but not in the target or baseline. this is an indication that it’s a new object that needs to be added to the target.
- do nothing with table3. table3 appears in the target, but not in the source or baseline. this is an indication that the object was added on the target only and the change needs to be preserved.
- create a conflict alert on proca. proca was changed, both on the source and on the target. using the baseline, we know that and display the three versions, allowing the devops to decide which version to take. in this case we will merge the changes.
- thus, prod would end up as follows:
these steps allow you to perform an intelligent three-way, baseline-aware analysis of your database so you can get your automation under way correctly.
Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.