customChange and updateSQL

General Discussion
1

Hi,

In all our test environments we let liquibase run the database upgrade by itself using “liquibase update”.

However, in our production environment we want to extract an SQL-script to give to the DBA.

So my question is: How does updateSQL react on a changeset containing customChange.

Using 1.9.3 (possibly 1.9.5)

Best regards
/Lasse

2

If I remember correctly in 1.9, the  updateSQL will still work with customChange classes, as long as the custom change returns SQL from the generateSQL method. 

Nathan 

3

Do you mean as return value of getConfirmationMessage?

http://www.liquibase.org/api/liquibase/change/custom/CustomTaskChange.html

4

That is what is outputted to the log message after the change runs. 

If you want a custom change that generates SQL, you will want to use http://www.liquibase.org/api/liquibase/change/custom/CustomSqlChange.html instead of CustomTaskChange

Nathan

5
Originally posted by: Nathan
That is what is outputted to the log message after the change runs.

How do I control what is outputted to “the log message”?

6

Not sure what you mean.  The getConfirmationMessage() is called and the return value from that will be sent to the log at update/updateSql time.  The SQL ran or saved with updateSql is the value returned from generateStatements()

Nathan

7

I want to use the CustomTaskChange (not CustomSQLChange) interface and implement that. The logic in that class performs the updates to the database directly when i run “update”.

But, if I then run liquibase with updateSQL with a changeset executing that class, what will the output, that I want to result in a sql-script, be then?

Best regards /Lasse

8

Any input on this? Thx /Lasse

9

Sorry, got pushed to the end of my queue over the holiday.

If you are using the CustomTaskChange, nothing will end up in the updateSQL mode, unfortunately.  That is the difference between the CustomTaskChange and the CustomSQLChange.  The CustomTaskChange allows you to do whatever you want, with the problem that we can not track what you are doing to include it in an updateSQL run.

Liquibase 2.0 gives you a lot more power and flexibility with custom changes, you may want to look into that if CustomSQLChange will not work for you.

Nathan

10

Hi Nathan,

Ok that was what I figured.

Then, the CustomTaskChange is not fully compatible with the commands that liquibase provide. Let us say that we agree to execute all changes automatically in all environments but the production environment. In the production environment we want to, for safety and organizational reasons, generate a SQL-script that we will investigate and then give to our DBA.

In that scenario, I see no way we can use CustomTaskChange.

My opinion then (if above is true) is that the overall concept with Liquibase does not work properly when using CustomTaskChange.

11

Yes, that is right, assuming you are using an updateSQL workflow.  Originally I was very strict on the “everything must work with updateSQL” rule and did not have a CustomTaskChange option.  Over time, however, there have been many requests for things that are very helpful in some workflows, but do not work with the updateSQL mode.  Eventually I decided that we should not limit what liquibase can do for some people so it will always work with a feature they may not be using.

With 2.0, I have began to introduce a feature that allows changes to give a warning if they do not support updateSQL mode to help end-users know what is safe and what is not.

Nathan

12

I’m having the same issue as svaret. Is there at least a way inside a CustomTaskChange to know whether or not Liquibase is being run in update mode vs updateSQL? Our DBA just ran updateSQL and our CustomTaskChange actually modified something in the database!


Also, you mentioned v2, I’m using v2 and I don’t see anything in the CustomTaskChange that differentiates between update and updateSQL. Is there some other mechanism I should be using for custom changes?

13

Hi,


I know this is an older topic, but I’ve just run into the same situation:  my requirements necessitate a CustomTaskChange which updates the database directly. 


Now I would like to add a “verify” mode to fit into the “updateSQL” model.


I see two alternatives:


(1) change my CustomTaskChange into a CustomSqlChange that (still) modifies the database directly and returns an “sql comment” describing the changes made. Question:  will the side effects break the semantics of the change process?


or 


(2) adding  to the interface CustomTaskChange an additional method, perhaps:


              execute(Database database, Writer output)


or (only somewhat tongue-in-cheek):

               

              dontExecute(Database database, Writer output)


which would write a log of sql comments describing the changes that would have been executed and not modify the database.



Thoughts?


Thanks,



Mark

14

Have you taken a look at the new extension system with 2.0 (liquibase.org/extensions) to see if that will give you more options?

Nathan

15

If I understand correctly, my extension would extend AbstractChange.


My question is:  how does my method implementing “generateStatements()” know whether this is “update” - make the changes to the database - or “updateSQL” - do not make database changes.


I’m guessing that the following test within my extension’s generateStatements() method will work but seems very un-clean:


  1. if (ExecutorService.getInstance().getExecutor(database) instanceof LoggingExecutor)
  2. {
  3.     // generateSQL - do not change database
  4. }
  5. else
  6. {
  7.     // generate - make database changes as side effect
  8. }


The knowledge of whether this is “generate” vs. “generateSQL” seems to be completely contained in Main.