--- a/liquibase.rst Tue Dec 22 22:29:09 2015 +0200
+++ b/liquibase.rst Wed Dec 23 12:19:32 2015 +0200
@@ -68,6 +68,11 @@
Now my file is safely can be applied to production database without loosing
data and can recreate new schema in empty database.
+ * http://www.operatornew.com/2012/11/automatic-db-migration-for-java-web.html
+ * http://www.baeldung.com/liquibase-refactor-schema-of-java-app
+ * http://www.liquibase.org/documentation/existing_project.html
+ * http://www.liquibase.org/tutorial-using-oracle
+
Generate difference between databases.
======================================
@@ -292,7 +297,7 @@
</changeSet>
SQL syntax also have ``logicalFilePath`` attribute for top level file mark
-(implemented in v3.3):
+(implemented in v3.3)::
--liquibase formatted sql logicalFilePath:legacy.sql
@@ -329,3 +334,65 @@
``liquibase-core/src/main/java/liquibase/parser/core/formattedsql/FormattedSqlChangeLogParser.java``
for further info .
+Split changesets into files.
+============================
+
+It is not possible to split file formatted in SQL LiquiBase syntax.
+
+It is not possible to set tag with SQL LiquiBase syntax. To workaround this
+issue you may split SQL file and set tags in XML sytax::
+
+ <changeSet author="master" id="1">
+ <tagDatabase tag="v0.1"/>
+ </changeSet>
+
+ <include file="legacy.sql" relativeToChangelogFile="true"/>
+
+ <changeSet author="master" id="2">
+ <tagDatabase tag="v1.0"/>
+ </changeSet>
+
+ <include file="v1.0.sql" relativeToChangelogFile="true"/>
+
+Also you should be interested in storing stored procedures in separate file and
+apply ``runOnChange`` attribure for XML syntax::
+
+ <changeSet author="admin" id="proc-hello">
+ <createProcedure
+ runOnChange="true"
+ encoding="utf8"
+ dbms="oracle">
+ CREATE OR REPLACE PROCEDURE hello AS
+ BEGIN
+ DBMS_OUTPUT.PUT_LINE('Hello');
+ END;
+ </createProcedure>
+ </changeSet>
+
+or with SQL syntax::
+
+ --changeset admin:proc-hello runOnChange:true
+ CREATE OR REPLACE PROCEDURE hello AS
+ BEGIN
+ DBMS_OUTPUT.PUT_LINE('Hello');
+ END;
+
+Some people suggest to use one file per stored procedure / package.
+
+How big chould be changeset?
+============================
+
+Less is better.
+
+Some databases doesn't support transactional DDL (e.g. Oracle, SQL Server), each
+DDL statement should be put into a single changeset.
+
+Putting unrelated operations into single changeset leads to trouble when last or
+intermediate of them fail to apply.
+
+Try to group constraint adding in corresponding update statements. If you have
+wrong update that doesn't prepare data to constraint it shouldn't be commited
+but rewritten.
+
+ * http://blog.mgm-tp.com/2010/11/data-modeling-part2/
+