/
init.xml
123 lines (103 loc) · 5.33 KB
/
init.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright 2010-2017 the original author or authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<document xmlns="http://maven.apache.org/XDOC/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
<properties>
<title>MyBatis Migrations | Migrate > Init</title>
<author email="mybatis-dev@googlegroups.com">The MyBatis Team</author>
</properties>
<body>
<section name="The 'init' command">
<p>The <strong>init</strong> command initializes a new 'migration path', also called a 'repository' (of migration scripts). Regardless of whether your working with a new database or an existing one, you'll run init to create the workspace in which you'll place everything you need to manage database
change. Running this command will create the directory specified by the <code>--path</code> option (which is the current working directory by default).
Here's an example of running the init command:</p>
<source>/$ migrate --path=/home/cbegin/testdb init</source>
<p>If I was already in the <code>/home/cbegin/testdb</code> directory, I could simply run:</p>
<source>/home/cbegin/testdb$ migrate init</source>
<p>When the command is completed, the directory will contain the following sub-directories:</p>
<p>Since version 3.2.1, you can change the default timestamp based file prefix to number sequence by specifying <code>--idpattern</code> option. With the following command, for example, the prefix of the generated scripts will be three digit zero-padded number like '001'.</p>
<source>/home/cbegin/testdb$ migrate --idpattern=000 init</source>
<p>Instead of specifying the pattern as a command line argument, you can set it in the configuration file <code>$MIGRATIONS_HOME/migration.properties</code> as follows.</p>
<source># Example of migration.properties
idpattern=000</source>
<subsection name="./drivers">
<p>Place your JDBC driver .jar or .zip files in this directory. Upon running a migration, the drivers will be dynamically loaded.</p>
</subsection>
<subsection name="./environments">
<p>
In the environments folder you will find .properties files that represent your database instances. By default a
<strong>development.properties</strong>
file is created for you to configure your development time database properties. You can also create test.properties
and production.properties files. Details about the properties themselves follow later in this document. The
environment can be specified when running a migration by using the
<code>--env=<environment></code>
option (without the path or ".properties" part).
</p>
<p>The default environment is "development". The properties file is self documented, but here it is for reference:</p>
<source><![CDATA[## Base time zone to ensure times are consistent across machines
time_zone=GMT+0:00
## The character set that scripts are encoded with
# script_char_set=UTF-8
## JDBC connection properties.
driver=
url=
username=
password=
# Name of the table that tracks changes to the database
changelog=CHANGELOG
# If set to true, each statement is isolated
# in its own transaction. Otherwise the entire
# script is executed in one transaction.
auto_commit=false
# This controls how statements are delimited.
# By default statements are delimited by an
# end of line semicolon. Some databases may
# (e.g. MS SQL Server) may require a full line
# delimiter such as GO.
delimiter=;
full_line_delimiter=false
# This ignores the line delimiters and
# simply sends the entire script at once.
# Use with JDBC drivers that can accept large
# blocks of delimited text at once.
send_full_script=true
# If set to false, warnings from the database
# will interrupt migrations.
ignore_warnings=true
# Custom driver path to avoid copying your drivers
# driver_path=]]></source>
<h4>Database specific information</h4>
<h5>MySQL</h5>
<ul>
<li><code>send_full_script</code> must be set to <code>false</code> to execute a script with multiple statements.</li>
</ul>
</subsection>
<subsection name="./scripts">
<p>
This directory contains your migration SQL files. These are the files that contain your DDL to both upgrade and
downgrade your database structure. By default, the directory will contain the script to create the
<strong>changelog</strong>
table, plus one empty example migration script. To create a new migration script, use the
<strong>"new"</strong>
command. To run all pending migrations, use the
<strong>"up"</strong>
command. To undo the last migration applied, use the
<strong>"down"</strong>
command etc.
</p>
</subsection>
</section>
</body>
</document>