Liquibase : Migrate.sql does not check precondtions - liquibase

I use liquibase to generate SQL files based on the changeset . But when I am using liquibase:updateSQL , it is not checking for preconditions before generating the SQL file
I have a preconditions saying to check if the table exists , before creating the table .
In this scenario even though the tables are present the 'create table SQL statement is still getting generated.'
Where as when i run liquibase:update goal this precondition is checked properly .
So does not liquibase check for precondition while generating the sql file?
Thanks.

You probably have found an answer already, but just in case this might help:
http://forum.liquibase.org/topic/unexpected-behaviour-of-preconditions-with-updatesql
onSqlOutput="TEST" attribute for the precondition sounds like what you are looking for.
Just be careful with the the preconditions you write or when to test them while generating the updateSQL. Preconditions that rely on previously applied patches that might have not been executed yet in your instance could cause errors.
Hope it helps

Might help to provide some code. Especially your precondition to allow other to evaluate if it is an issue.

Related

How do I specify validchecksum to any in liquibase formatted sql?

I have run into an issue with liquibase. So , I made a mistake in my sql commands in one of the changesets. Now whenever I try to upgrade my deployment , the upgrade is failing due to wrong checksum.
So I thought of doing the validCheckSum : ANY workaround and have run into this issue where it is not working. So my question is , is there any mistake in my syntax and How do I bypass the checksum check or what is the proper syntax for setting any in liquibase formatted sql.
This is what I have tried
--changeset darth: build-1.3
--validCheckSum: build-1.3:ANY
and it doesnt work.
Please help! Thanks!
The docs say:
Special value "1:any" will match to any checksum
Not sure why did you put "build-1.3:ANY"?
Also what you can do is:
Execute your code with latest liquibase changes onto an empty database
In DATABASECHANGELOG table look for the rows with changeset ids that you have been changing
Copy the MD5SUM value and paste it into your changeSet definition as a value of validCheckSum
It should run on any database with already executed changesets without errors.
It is worth mentioning that altering a change set is not recommended: by setting a validCheckSum value you will have "old" changeset already executed and "new" changes to this change set will be skiped. On an empty database your "new" changeset will be executed, so you will potentially have model inconsistencies.

Is there a way to update a calculation view through a query on SAP HANA?

I'm working on updating hundreds of calculation views on SAP HANA.
I should update (for every calculation view) the last aggregation/projection columns : Keep flag = True.
There's a way, by updating XML Code of every calculation view file Like below:
<attribute id="EQUNR" order="3" attributeHierarchyActive="false"
displayAttribute="false" keepFlag="true">
<descriptions defaultDescription="EQUNR"/>
But, my question is, is there a way to update this Keep Flag through a query on SQL Console ?
if not, is there any other method you suggest guys ?
Every idea matters, Thank you folks
There is no way to achieve this via SQL.
Although you may be able to author a regex expression that matches some of the target XML tags, there’s no way of correctly updating the repository tables storing the source XML (if you’re using the HANA classic repository).
For HANA 2 HDI files no DB command can change the source code as these are not stored in the database.
Beyond this technical issue, it’s probably not a good idea to apply a flag that changes query semantics as a batch update.

How to use PLAN with UPDATE OR INSERT INTO

I am using Firebird 2.5 and came across a problem that I can not resolve by myself.
There is a statement using UPDATE OR INSERT INTO. I would like to make it use a specific execution plan. But - no matter where I place the PLAN - I get following error message (line number varies with PLAN's position):
Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Token unknown - line 2, column 5.
plan.
I did not find anything about the usage of PLAN with UPDATE OR INSERT INTO in the corresponding documentation.
Aspects of my question: Is it even possible to use them together? Does this work or is it planned to work in a later version of Firebird? Is there an obvious reason it does not work, that I did not see? Which alternatives exist to circumvent this?
It is not possible to do this in Firebird 2.5 (and also not possible in 3.0). Looking at the parser definition, the PLAN clause is only supported on:
select query specification
searched delete
searched update
For a merge statement it should be possible to specify a plan for the source (if it is a select query), but not for the merge itself. The plan clause is not defined for update or insert (nor is it for insert, for example).
As far as I am aware there is nothing planned to add this to Firebird 4. You should consider adding an improvement ticket in the tracker, but I don't know if this is even possible at all.

How can I programmatically run arbitrary SQL statements against my Hibernate/HSQL database?

I'm looking for a way to programmatically execute arbitrary SQL commands against my DB.
(Hibernate, JPA, HSQL)
Query.createNativeQuery() doesn't work for things like CREATE TABLE.
Doing LOTS of searching, I thought I could use the Hibernate Session.doWork().
By using the deprecated Configuration.buildSesionFactory() seems to show that doWork won't work.
I get "use lacks privilege or object not found" for all the CREATE TABLE statements.
So, what other technique is there for executing arbitratry SQL statements?
There were some notes on using the underlying JDBC Statement, but I haven't figure out how to get a JDBC Connection object from Hibernate to try that.
Note that the hibernate.hbm2ddl.auto=create setting will NOT work for me, as I have ARRAY[] columns which it chokes on.
I don't think there is any problem executing a create table statement with a Hibernate native query. Just make sure to use Query.executeUpdate(), and not Query.list() or Query.uniqueResult().
If it doesn't work, please tell us what happens when you execute it, and join the full stack trace of the exception and the SQL query you're executing.
"use lacks privilege or object not found" in HSQL may mean anything, for example existence of a table with the same name. Error messages in HSQL are completely misleading. Try listing your tables using DatabaseMetadata - you have probably already created the table.

Getting the SQL from a Doctrine Migration

I have been researching a way to get the SQL statements that are built by a generated Migration file. These extend Doctrine_Migration_Base. Essentially I would like to save the SQL as change scripts.
The execution path leads me to Doctrine_Export which has methods that build the SQL statement and executes them. I have found no way of asking for just them. The export methods found in Doctrine_Export only operate on Doctrine_Record models and not Migration scripts.
From the command line './doctrine migrate version#' the path goes:
Doctrine_Cli::run(cmd)
Doctrine_Task_Migrate::setArguments(args)
Doctrine_Task_Migrate::execute()
Doctrine_Migration::migrate(to)
Doctrine_Migration_Process::Doctrine_Export::various
create, drop, alter methods with sql
equivalents.
Has anyone tackled this before? I really would not like to change Doctrine base files. Any help is greatly appreciated.
Could you make a dev server, and do the migration on that, storing a SQL Trace as you go?you don't have to keep the results, but you would get a list of every command.
Taking into account Rob Farley's suggestion, I modified:
Doctrine_Core::migrate
Doctrine_Task_Migrate::execute
When the execute method is called the optional argument 'dryRun' is checked. If true
then a 'Doctrine_Connection_Profiler' instance is created. The 'dryRun' value is then passed onto
the 'Doctrine_Core::migrate' method. The 'dryRun' value of true allows the changes to rollback when done executing the SQL statements. When the method returns, the profiler is parsed and non-empty SQL statements
not containing 'migration_version' are saved and displayed to the terminal.