Quantcast
Channel: Liquibase Forums
Viewing all 1169 articles
Browse latest View live

Re : Automatic rollback support - how is this invoked for create table failure

$
0
0
I think that the term 'rollback' as used by Liquibase is giving a mistaken idea about how it functions. This is especially true for people who work with databases all the time and think of rollback in a database transaction. 

Liquibase does not automatically roll back changes made during a deploy if there was an error. Rather, it can roll a database back to a previous schema state when you ask it to. In some cases, it can do that without you explicitly saying how to do the rollback.

It would be better to think of the rollback command in Liquibase as 'undo deploys' rather than a transactional rollback.

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/

Re : Automatic rollback support - how is this invoked for create table failure

$
0
0
Thanks Steve,

I think I see what you mean now so we can say for two changesets to tell them to simply rollback and they will know how to do this e.g. if createTable was used? That still sounds useful perhaps the command name should be called "undo" rather than rollback then.

However how would you also best handle the scenario I mentioned e.g. creation of a table succeeds in one part of the changeset and the second table creation fails?

Re : Automatic rollback support - how is this invoked for create table failure

$
0
0
If you continue with Liquibase, the best way to deal with this is to fix your changelog so that the problem doesn't happen again. Unfortunately, when the scenario you described happens, the database can be left in an uncertain state, which is why it is considered a 'best practice' to limit changesets to a single change. 

The recommendation when using Liquibase is to test your database deploy process in development, then in test, then in staging, then in production. If you are disciplined about not allowing changes in the different environments except through Liquibase, by the time you get out of development you will typically have found the issues like this and when you get to later environments deploying your database changes becomes completely routine. 

You can also use preconditions to check whether some condition is true or not, and then only apply the changeset in one of those cases. I feel like that is a 'code smell' that is best avoided if possible.

If you would consider looking at Datical DB, then we have written extensions to Liquibase that make these kinds of workflows more automated. For example, we have a command "deployOrAutoRollback" that does what you are looking for. We have also extended Liquibase to support more database object types, a rules engine that can help automate the checks your DBAs might be doing, and many other features. 

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/

"Cluster-safe database upgrades" liquibase benefit mentioned - what does this mean?

$
0
0
Team,

I noticed this term was used 

  • Cluster-safe database upgrades
on 


Does anyone know exactly what is meant by it and how liquibase supports this through it's framework?

Thanks

Re : Contexting of include tags?

$
0
0
I didn't fully understand what you meant by this however did you find a solution as this thread is a year old with no responses

Re : Contexting of include tags?

$
0
0
Hi,
I have made a question linked to this one in the forum. I know that in version 3.5.1 it's supposed to be able to specify the context at changelog level in the include statement but I was trying without success.
Could someone explain me how it works this new function?

Thanks in advance

Dealing with changing changesets within a release cycle

$
0
0
Team,

I was interested in how most teams handle schema changes which are really fixes for earlier changesets e.g. updating the correct field value which is changed a few times within a release i.e. before any customer would ever test.  e.g. consider

1) UPDATE CONFIGPARAMS SET VALUE='MYVALUE1'
2) UPDATE CONFIGPARAMS SET VALUE='MYVALUE2
3) UPDATE CONFIGPARAMS SET VALUE='MYVALUE3''

Suppose by changeset 3 this was the GA candidate. When we generated our SQL to deploy to the customer we wouldn't really want three update statements when only the last was intended.  

This page provides some options


However the most appropriate solution I can see this page lists is

"In this case, it is best to use add a <validCheckSum> tag to the changeSet specifying that the new check sum is correct"

Although in other documentation references it indicates this isn't a best practise i.e.


validCheckSumList checksums which are considered valid for this changeSet, regardless of what is stored in the database. Used primarily when you need to change a changeSet and don't want errors thrown on databases on which it has already run (not a recommended procedure). Since 1.7
What is cleanest way to handle this here? What are others currently doing?

Many thanks

Matt 

updateToTagSQL and updateSQL

$
0
0
Hello,

In my setup I have multiple databases managed with liquibase scripts. As I have many of the DBs I don't create DB tag for each of the databases for each of the product release (I add tag a DB only when there were some changes to the schema in the current product release).

I have a following steps executed in my build:


Let's say that we have a database DB1, which has following change sets:
- createTable1
- tag 1.4.0
- modifyTable1
and that we had a product released with version 1.5.0 (i.e. there are other databases that are tagged with 1.5.0 but not this one as there were no changes in this particular DB since 1.4.0 product release).

When I run following steps:
1. "Simulate" having a production DB in a specific product release version. I don't have a current DB1 db tag, only the product release version - 1.5.0:
liquibase updateToTagSQL 1.5.0 (with URL "offline:postgresql?changeLogFile=baseChangeLog.csv")

2. Generate update SQL script based on "baseChangeLog.csv" (so it can be applied manually against the production database):
liquibase updateSQL (with URL "offline:postgresql?changeLogFile=baseChangeLog.csv")

I would expect that liquibase will notice that the latest tagged version is 1.4.0 (based on the csv generated in step #1) and the second step will include all modifications after tag 1.4.0. Unfortunately, instead I get an empty SQL.

Any hints what I am doing incorrectly?

I was thinking about auto-detecting what is the latest tag for a given database to use a latest tag for updateToTagSQL instead of the latest product release version. I tried to check the generated baseChangeLog.csv file but it's tag column is always empty.

I could also add tags for every release, but as I am trying to automate release procedure, it's quite complex to modify existing SQL scripts to add another tag command (we I am using Groovy DSL and multiple includes).

Any suggestions are welcomed!

Best regards,
Piotr

Deployment_id in 3.5.3

$
0
0
Just had a question about this feature, is deployment_id is generated automatically? Any way to control (or supply) the value? 

The reason I ask is, we use multiple contexts (each context represents a single schema in Oracle DB) and we always run for all contexts (about 7-8) that we have.

If I could control deployment_id, i could use that for all contexts, so i can easily track all changesets for a given deployment (aka release). 

I searched in docs but there is no mention of that yet, hence this question.

Thanks

Re : "Cluster-safe database upgrades" liquibase benefit mentioned - what does this mean?

$
0
0
I think it simply means that a lock table is used to perform migrations. Thus, if 2 instances of an application execute migrations at the same time, one is performing and the other one is waiting until the lock is free again.

DATABASECHANGELOG table type MyISAM or InnoDB?

$
0
0
I just noticed that the lock table is created with InnoDB engine type, and DATABASECHANGELOG with MyISAM.
Is this a problem on my side, or intentionally?

IncludeAll runs twice once with logical path and once with absolute path

$
0
0
Hi,

I am using Liquibase Version: 3.5.3 and when I used the includeAll, all scripts in that folder were run twice. Once with absolute path and once with relative. I tried all options like relativeToChangelogFile="true" and logicalFilePath="stripPath". I am using commando line to execute and sqlFormatted in scripts. 

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
logicalFilePath="stripPath"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd
http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">


<includeAll path="install/tab/" />
<include file="install/foreignKeys.sql" />

</databaseChangeLog>

Liquibase creates log tables with user schema

$
0
0
When implementing liquibase on Sql Server. Below tables are created on USER schema not with DBO schema. Not sure how to fix this. 

AMAR.DATABASECHANGELOG
AMAR.DATABASECHANGELOGLOCK

It shoule be 
DBO.DATABASECHANGELOG
DBO.DATABASECHANGELOGLOCK 

I don't have any issues on creating table. It always creates on DBO schema. I'm using integratedSecurity and Liquibase version is 3.4.2

--liquibaseSchemaName doesn't work with Postgres

$
0
0
I am trying to move the liquibase tables into a different schema using the parameter --liquibaseSchemaName, e.g using --liquibaseSchemaName=liquibase

This works for the initial creation of the tables and the very first run of a changeLog.

But the test if the tables are present is apparently ignoring that parameter but the creation code itself is not. So on the second run, the following error occurs:

Unexpected error running Liquibase: ERROR: relation "databasechangelog" already exists

SEVERE 10/21/16 8:43 AM: liquibase: ERROR: relation "databasechangelog" already exists
liquibase.exception.DatabaseException: ERROR: relation "databasechangelog" already exists [Failed SQL: CREATE TABLE liquibase.databasechangelog (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL,
 FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED TIMESTAMP WITHOUT TIME ZONE NOT NULL, ORDEREXECUTED INT NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35), DESCRIPTION VARCHAR(255), COMMENTS VA
RCHAR(255), TAG VARCHAR(255), LIQUIBASE VARCHAR(20), CONTEXTS VARCHAR(255), LABELS VARCHAR(255), DEPLOYMENT_ID VARCHAR(10))]

Re : --liquibaseSchemaName doesn't work with Postgres

$
0
0
I just saw that there is already a version 3.5.3 which seems to have fixed this bug (I was testing with 3.5.1)

Sorry for the noise

Re : IncludeAll runs twice once with logical path and once with absolute path

$
0
0
I'm not sure however I'd suggest firstly adding verbose debug logging. Then you could debug in DatabaseChangeLog.java

    public void includeAll(String pathName, boolean isRelativeToChangelogFile, IncludeAllFilter resourceFilter,

                           boolean errorIfMissingOrEmpty,

                           Comparator<String> resourceComparator, ResourceAccessor resourceAccessor, ContextExpression includeContexts) throws SetupException {

        try {

 

Re : "Cluster-safe database upgrades" liquibase benefit mentioned - what does this mean?

$
0
0
Yes although it would seem odd for two separate processes to be attempting to process upgrades against the database at the same time. 

Re : "Cluster-safe database upgrades" liquibase benefit mentioned - what does this mean?

$
0
0
The main use case is when you have Liquibase to auto-run on startup of a web application, and you have a cluster of servers that may end up being started at the same time..

Nathan

If you like Liquibase, you’ll love Datical DB

$
0
0
Thanks for checking out Liquibase. If you work for a big company and are thinking about using Liquibase you will want to check out Datical DB. It has all things you like about Liquibase plus capabilities every enterprise needs – like change forecasting, rules enforcement, extended object support, reporting and more. Find out more here: ttp://www.datical.com/liquibase/

Nathan
LiquibaseBenevolent Dictator for Life

Re : IncludeAll runs twice once with logical path and once with absolute path

$
0
0
also be wary of issues with includeAll from 

http://www.liquibase.org/documentation/includeall.html

While the includeAll tag has many valuable uses, its use can cause problems down the road. The biggest thing to avoid is to use the includeAll tag to simulate Ruby on Rails Active Migrations strategy of a list of changes, one per file, that are ran in file order. While this seems like a good idea at first, it quickly runs into problems


Viewing all 1169 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>