Unfortunately we don't use Liquibase built-in tags at work and it's already too late to fix the existing changesets. Has anyone tried to pass parameters to queries wrapped in CDATA tag without modifying the Liquibase maven plugin? However, Adding a new maven build plugin is ok.
<changeSet id="XXXXX" author="Mehrad">
<sql>
<![CDATA[
DO SOMETHING USING THE PARAMETER..
]]>
</sql>
<rollback><sql><![CDATA[ do something else ]]></sql></rollback>
</changeSet>
Liquibase support changelog paramters which I think is what you are looking for. You should be able to use then in CDATA blocks, especially with the later (3.2.2+) versions of Liquibase.
Related
I am using Quarkus 2.9.2.Final and would like to set a Hibernate config parameter, which is not one of the "chosen ones" which can go into Quarkus' application.properties as per the documentation.
Specifically I would like to set this Hibernate configuration property:
<property name="hibernate.hql.bulk_id_strategy"
value="org.hibernate.hql.spi.id.inline.InlineIdsInClauseBulkIdStrategy"
/>
to prevent Hibernate from generating temporary tables (as described here).
How can I achieve this?
Have you tried the quarkus.hibernate-orm.unsupported-properties (ref) config?
we are using liquibase for migrating database in spring boot application. In resources we have main changelog file which includes other changelogs (1 per version).
We usually differentiate environments by liquibase's context attribute but new we need differentiate data which are only for integration tests, and don't want place it next to normal versioned scripts. Is possible place these integration tests scripts in test's scope of project and execute them in order with normal scripts?
For instance:
main changelog:
<include file="version-1.xml"/>
<include file="version-2.xml"/>
and version 1 sample:
<changeSet id="1ver_1" author="xxx">
<!-- creation of table foo_table -->
</changeSet>
<changeSet id="1ver_2" author="xxx">
<!-- adding column to table foo_table -->
</changeSet>
version 2 sample:
<changeSet id="2ver_1" author="xxx">
<!-- renaming table foo_table to bar_table -->
</changeSet>
I need that if scripts for integration tests will written after script 1ver_1 and will contains inserts, it will be ok if next will be executed 1ver_2 and 2ver_1.
So when db for instegration tests started, scripts will be executed in right order:
1ver_1
test_data for 1ver_1
1ver_2
2ver_1
what is best practice to do that?
I think you should change the way you keep your changesets. Have a look at Liquibase Best Practices.
So your master changelog should look like:
<include file="version-1.1.xml"/>
<include file="version-1.2.xml"/>
<include file="version-2.1xml"/>
If you do this, you can have dedicated master changelog file for integration test. Your integration test's changelog-master.xml will look like this:
<include file="version-1.1.xml"/>
<include file="test_data_version-1.1.xml"/>
<include file="version-1.2.xml"/>
<include file="version-2.1xml"/>
After that you just override property in integration tests:
liquibase.change-log=classpath:integration-liquibase-changeLog.xml
Also you should place integration-liquibase-changeLog.xml and all 'test_data_xx.xml' into integration test module resource or test resource (it depends on project structure). The main idea it should not be provided to production artifacts.
I have configured the liquibase migration for my Spring Boot application. Now I have a chagelog folder with all changes and I'd like to have a file with current database scheme because it's convenient. Does liquibase have best practices for storing actual db scheme in Spring Boot project?
Your question is confusing. When you say "a file with current database scheme", are you referring to the actual database with data (such as a SQLite file) or a script to create the database initial state?
If what you want is the actual database, this is not a liquibase concern. You could certainly put the database file in the same folder as the scripts, but that would not make a lot of sense to me. The liquibase scripts should be considered part of your source code, the database is execution environment specific and probably belongs elsewhere.
If you want a script for the initial state, that is absolutely something you can do with liquibase. The command you want is generateChangeLog. This will analyse your existing database and generate a changelog to recreate it. You would then refer to it as the first changelog to execute in your scripts.
java -jar liquibase.jar
--classpath=sqlitejdbc-v<version>.jar
--driver=org.sqlite.JDBC
--url="jdbc:sqlite:exampledb.sqlite"
--changeLogFile=db.changelog.initial-state.xml
generateChangeLog
<?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"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.4.xsd">
<include file="db.changelog.initial-state.xml" />
<changeSet author="captain" id="diff1">
do some stuff
</changeset>
<changeSet author="captain" id="diff2">
do some more stuff
</changeset>
...
What is a NamespaceHandler? What is the need to write our custom NamespaceHandler?
Please explain me the significance of NamespaceHandler. Provide me Any links on internet.
It handles specific XML tags found inside a file, such as <log:return />, which is the return tag inside the log namespace.
The best reference is often the Javadoc.
It is useful if you want to use your custom XML tags in an XML configuration:
http://www.theserverside.com/news/1364131/Authoring-Custom-Namespaces-in-Spring-20
If you have a framework and want to add Spring integration to your framework, it could be useful. In that case it would be more important to define the equivalent annotations.
I'm using the cxf-codegen-plugin to generate some classes from a WSDL. After the sources are generated, a bunch of beans get deleted (we don't need them, just the service interfaces), but there is an #XmlSeeAlso annotation in the generated source that references some of these deleted classes. We don't need the #XmlSeeAlso annotation at all, is there a way to tell the cxf-codegen-plugin to exclude certain annotations when generating sources?
I solved this by adding a tag to a maven-antrun-plugin, commenting out all the #XmlSeeAlso instances:
<target>
<replace file="${basedir}/target/generated-sources/x/x/x/Service.java" token="#XmlSeeAlso" value="//#XmlSeeAlso" />
</target>
The idea of generated code is to let it be as it is. The question is why would you like to delete files which i assume is manual work which is in contradiction to the idea of generated code.