1 .. -*- coding: utf-8 -*- |
|
2 |
|
3 .. _migration: |
|
4 |
|
5 Migration |
|
6 ========= |
|
7 |
|
8 One of the main concept in `CubicWeb` is to create incremental applications |
|
9 and for this purpose multiple actions are provided to facilitate the improvement |
|
10 of an application and in particular changes applied to the data model |
|
11 without loosing existing data. |
|
12 |
|
13 The current version of an application model is provided in the file |
|
14 `__pkginfo__.py` as a tuple of 3 integers. |
|
15 |
|
16 Migration scripts management |
|
17 ---------------------------- |
|
18 |
|
19 Migration scripts needs to be located in the directory `migration` of your |
|
20 application and nammed accordingly: |
|
21 |
|
22 :: |
|
23 |
|
24 <version n° X.Y.Z>[_<description>]_<mode>.py |
|
25 |
|
26 in which : |
|
27 |
|
28 * X.Y.Z is the model version number to which the script enable to migrate |
|
29 |
|
30 * *mode* (between the last "_" and the extension ".py") indicates which part |
|
31 of the application (RQL server, web server) the script applies to in case |
|
32 of distributed installation. Its value could be : |
|
33 |
|
34 * `common`, applies to the RQL server as well as the web server and updates |
|
35 files on the hard drive (configuration files migration for example). |
|
36 |
|
37 * `web`, applies only to the web server and updates files on the hard drive |
|
38 |
|
39 * `repository`, applies only to the RQL server and updates files on the |
|
40 hard drive |
|
41 |
|
42 * `Any`, applies only to the RQL server and updates data in the database |
|
43 (schema and data migration for example) |
|
44 |
|
45 Again in the directory `migration`, the file `depends.map` allows to indicate |
|
46 that to migrate to a particular model version, you always have to first migrate |
|
47 to a particular `CubicWeb` version. This file can contains comments (lines |
|
48 starting by `#`) and a dependancy is listed as follows: :: |
|
49 |
|
50 <model version n° X.Y.Z> : <cubicweb version n° X.Y.Z> |
|
51 |
|
52 For example: :: |
|
53 |
|
54 0.12.0: 2.26.0 |
|
55 0.13.0: 2.27.0 |
|
56 # 0.14 works with 2.27 <= erudi <= 2.28 at least |
|
57 0.15.0: 2.28.0 |
|
58 |
|
59 Base context |
|
60 ------------ |
|
61 |
|
62 The following identifiers are pre-defined in the migration scripts: |
|
63 |
|
64 * `config`, instance configuration |
|
65 |
|
66 * `interactive_mode`, boolean indicating that the script is executed in |
|
67 an intercative mode or not |
|
68 |
|
69 * `appltemplversion`, application model version of the instance |
|
70 |
|
71 * `applerudiversion`, cubicweb instance version |
|
72 |
|
73 * `templversion`, installed application model version |
|
74 |
|
75 * `erudiversion`, installed cubicweb version |
|
76 |
|
77 * `confirm(question)`, function interrogating the user and returning true |
|
78 if the user answers yes, false otherwise (always returns true when in a |
|
79 non-interactive mode) |
|
80 |
|
81 * `_`, function fonction equivalent to `unicode` allowing to flag the strings |
|
82 to internationalize in the migration scripts |
|
83 |
|
84 In the `repository` scripts, the following identifiers are also defined: |
|
85 |
|
86 * `checkpoint`, request confirming and executing a "commit" at checking point |
|
87 |
|
88 * `repo_schema`, instance persisting schema (e.g. instance schema of the |
|
89 current migration) |
|
90 |
|
91 * `newschema`, installed schema on the file system (e.g. schema of |
|
92 the updated model and erudi) |
|
93 |
|
94 * `sqlcursor`, SQL cursor for very rare cases where it is really |
|
95 necessary or beneficial to go through the sql |
|
96 |
|
97 * `repo`, repository object |
|
98 |
|
99 |
|
100 Schema migration |
|
101 ---------------- |
|
102 The following functions for schema migration are available in the `repository` |
|
103 scripts: |
|
104 |
|
105 * `add_attribute(etype, attrname, attrtype=None, commit=True)`, adds a new |
|
106 attribute to an existing entity type. If the attribute type is not specified, |
|
107 then it is extracted from the updated schema. |
|
108 |
|
109 * `drop_attribute(etype, attrname, commit=True)`, removes an attribute from an |
|
110 existing entity type. |
|
111 |
|
112 * `rename_attribute(etype, oldname, newname, commit=True)`, rename an attribute |
|
113 |
|
114 * `add_entity_type(etype, auto=True, commit=True)`, adds a new entity type. |
|
115 If `auto` is True, all the relations using this entity type and having a known |
|
116 entity type on the other hand will automatically be added. |
|
117 |
|
118 * `drop_entity_type(etype, commit=True)`, removes an entity type and all the |
|
119 relations using it. |
|
120 |
|
121 * `rename_entity_type(oldname, newname, commit=True)`, renames an entity type |
|
122 |
|
123 * `add_relation_type(rtype, addrdef=True, commit=True)`, adds a new relation |
|
124 type. If `addrdef` is True, all the relations definitions of this type will |
|
125 be added. |
|
126 |
|
127 * `drop_relation_type(rtype, commit=True)`, removes a relation type and all the |
|
128 definitions of this type. |
|
129 |
|
130 * `rename_relation(oldname, newname, commit=True)`, renames a relation. |
|
131 |
|
132 * `add_relation_definition(subjtype, rtype, objtype, commit=True)`, adds a new |
|
133 relation definition. |
|
134 |
|
135 * `drop_relation_definition(subjtype, rtype, objtype, commit=True)`, removes |
|
136 a relation definition. |
|
137 |
|
138 * `synchronize_permissions(ertype, commit=True)`, synchronizes permissions on |
|
139 an entity type or relation type. |
|
140 |
|
141 * `synchronize_rschema(rtype, commit=True)`, synchronizes properties and permissions |
|
142 on a relation type. |
|
143 |
|
144 * `synchronize_eschema(etype, commit=True)`, synchronizes properties and persmissions |
|
145 on an entity type. |
|
146 |
|
147 * `synchronize_schema(commit=True)`, synchronizes the persisting schema with the |
|
148 updated schema (but without adding or removing new entity types, relations types |
|
149 or even relations definitions). |
|
150 |
|
151 * `change_relation_props(subjtype, rtype, objtype, commit=True, **kwargs)`, changes |
|
152 properties of a relation definition by using the nammed parameters of the properties |
|
153 to change. |
|
154 |
|
155 * `set_widget(etype, rtype, widget, commit=True)`, changes the widget used for the |
|
156 relation <rtype> of entity type <etype>. |
|
157 |
|
158 * `set_size_constraint(etype, rtype, size, commit=True)`, changes the size constraints |
|
159 for the relation <rtype> of entity type <etype>. |
|
160 |
|
161 Data migration |
|
162 -------------- |
|
163 The following functions for data migration are available in the `repository` scripts: |
|
164 |
|
165 * `rql(rql, kwargs=None, cachekey=None, ask_confirm=True)`, executes an arbitrary RQL |
|
166 query, either to interrogate or update. A result set object is returned. |
|
167 |
|
168 * `add_entity(etype, *args, **kwargs)`, adds a nes entity type of the given |
|
169 type. The attributes and relations values are specified using the nammed and |
|
170 positionned parameters. |
|
171 |
|
172 Workflow creation |
|
173 ----------------- |
|
174 |
|
175 The following functions for workflow creation are available in the `repository` |
|
176 scripts: |
|
177 |
|
178 * `add_state(name, stateof, initial=False, commit=False, **kwargs)`, adds a new state |
|
179 in the workflow. |
|
180 |
|
181 * `add_transition(name, transitionof, fromstates, tostate, requiredgroups=(), commit=False, **kwargs)`, |
|
182 adds a new transition in the workflow. |
|
183 |
|
184 You can find more details about workflows in the chapter :ref:`Workflow` . |
|
185 |
|
186 Configuration migration |
|
187 ----------------------- |
|
188 |
|
189 The following functions for configuration migration are available in all the |
|
190 scripts: |
|
191 |
|
192 * `option_renamed(oldname, newname)`, indicates that an option has been renammed |
|
193 |
|
194 * `option_group_change(option, oldgroup, newgroup)`, indicates that an option does not |
|
195 belong anymore to the same group. |
|
196 |
|
197 * `option_added(oldname, newname)`, indicates that an option has been added. |
|
198 |
|
199 * `option_removed(oldname, newname)`, indicates that an option has been deleted. |
|
200 |
|
201 |
|
202 Others migration functions |
|
203 -------------------------- |
|
204 Those functions are only used for low level operations that could not be |
|
205 accomplished otherwise or to repair damaged databases during interactive |
|
206 session. They are available in the `repository` scripts: |
|
207 |
|
208 * `sqlexec(sql, args=None, ask_confirm=True)`, executes an arbitrary SQL query |
|
209 * `add_entity_type_table(etype, commit=True)` |
|
210 * `add_relation_type_table(rtype, commit=True)` |
|
211 * `uninline_relation(rtype, commit=True)` |
|