-
-
Notifications
You must be signed in to change notification settings - Fork 81
/
SQL.yml
64 lines (62 loc) · 4.26 KB
/
SQL.yml
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
# This file describes the format that you can use to define a migration running custom sql statements.
# For complex SQL code you might prefer to use a plain-sql-file migration definition instead of the yaml/json format,
# see the main README file for details about that
-
type: sql
mode: exec
# You can define different sql statements at the same time for different database types
# NB: the sql statement should not be a SELECT one, at least for MySQL
mysql: ""
oracle: ""
postgresql: ""
sqlite: ""
# etc...
resolve_references: true|false # Defaults to false. Set this to enable resolving references found within the sql code.
# The format to be used for specifying the reference is as in the following example:
# UPDATE A SET B='etc' WHERE C=[reference:example_reference]
# The list in references tells the manager to store specific values for later use by other steps in the current migration.
# NB: these are NEW VARIABLES THAT YOU ARE CREATING. They are not used in the current migration step!
references: # Optional
# short syntax:
referenceId: attributeId # (possible values and meaning are explained for the 'long syntax')
# long syntax:
-
identifier: referenceId # A string used to identify the reference
attribute: attributeId # The attribute to get the value of for the reference (supports: affected_rows)
overwrite: true|false # Optional, default false. If not set, and the reference already exists, an exception is thrown
if: # Optional. If set, the migration step will be skipped unless the condition is matched
"reference:_ref_name": # name of a reference to be used for the test
_operator_: value # allowed operators: eq, gt, gte, lt, lte, ne, count, length, regexp, satisfies
-
type: sql
mode: query
# You can define different sql SELECT statements at the same time for different database types
mysql: ""
oracle: ""
postgresql: ""
sqlite: ""
# etc...
resolve_references: true|false # Defaults to false. Set this to enable resolving references found within the sql code.
# The format to be used for specifying the reference is as in the following example:
# SELECT A.* FROM B WHERE C=[reference:example_reference]
# The list in references tells the manager to store specific values for later use by other steps in the current migration.
# NB: these are NEW VARIABLES THAT YOU ARE CREATING. They are not used in the current migration step!
references: # Optional
# short syntax:
referenceId: attributeId # (possible values and meaning are explained for the 'long syntax')
# long syntax:
-
identifier: referenceId # A string used to identify the reference
attribute: attributeId # The attribute to get the value of for the reference (supports: count, results.ColNameXX
# where ColNameXX is a column in the results set).
# NB: take care: if the query returns more than one row, setting a reference with
# the value of a result set column _will fail_, unless you set `expect: any` or `expect: many`,
# in which case the reference value will be an array
overwrite: true|false # Optional, default false. If not set, and the reference already exists, an exception is thrown
expect: one|any|many # Optional. If set, the number of matched rows will be validated, and the type of values set to created references will change
# 'one': only one row should be matched; reference values will be scalars
# 'any': zero or more rows should be matched; reference values will be arrays
# 'many': one or more rows should be matched; reference values will be arrays
if: # Optional. If set, the migration step will be skipped unless the condition is matched
"reference:_ref_name": # name of a reference to be used for the test
_operator_: value # allowed operators: eq, gt, gte, lt, lte, ne, count, length, regexp, satisfies