~openerp-community/openobject-doc/ksa-openobject-doc-6.0

« back to all changes in this revision

Viewing changes to i18n/ru/source/developer/5_18_upgrading_server/index.rst

  • Committer: Don Kirkby
  • Date: 2011-02-21 20:46:11 UTC
  • mfrom: (433.1.53 openobject-doc)
  • Revision ID: donkirkby+launpd@gmail.com-20110221204611-1ykt6dmg4k3gh5dh
[MERGE] revisions 477 to 486 from the 5.0 branch.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
 
 
2
.. i18n: .. warning:: This section needs to be rewritten or improved. If you think you
 
3
.. i18n:              can contribute to this effort, and are already familiar with Launchpad 
 
4
.. i18n:              and OpenERP's source control system, Bazaar, please have a look at:
 
5
.. i18n: 
 
6
.. i18n:                  * the section explaining how you can download and build the
 
7
.. i18n:                    current documentation on your system: :ref:`building_documentation`
 
8
.. i18n:                  * an RST primer such as `this one <http://sphinx.pocoo.org/rest.html>`_ to learn 
 
9
.. i18n:                    how you can start modifying the documentation content
 
10
..
 
11
 
 
12
.. warning:: This section needs to be rewritten or improved. If you think you
 
13
             can contribute to this effort, and are already familiar with Launchpad 
 
14
             and OpenERP's source control system, Bazaar, please have a look at:
 
15
 
 
16
                 * the section explaining how you can download and build the
 
17
                   current documentation on your system: :ref:`building_documentation`
 
18
                 * an RST primer such as `this one <http://sphinx.pocoo.org/rest.html>`_ to learn 
 
19
                   how you can start modifying the documentation content
 
20
 
 
21
.. i18n: .. _technical_update_procedure:
 
22
.. i18n: 
 
23
.. i18n: =========================
 
24
.. i18n: Upgrading Server, Modules 
 
25
.. i18n: =========================
 
26
..
 
27
 
 
28
.. _technical_update_procedure:
 
29
 
 
30
=========================
 
31
Upgrading Server, Modules 
 
32
=========================
 
33
 
 
34
.. i18n: The upgrade from version to version is automatic and doesn't need any special
 
35
.. i18n: scripting on the user's part. In fact, the server is able to automatically
 
36
.. i18n: rebuild the database and the data from a previously installed version.
 
37
..
 
38
 
 
39
The upgrade from version to version is automatic and doesn't need any special
 
40
scripting on the user's part. In fact, the server is able to automatically
 
41
rebuild the database and the data from a previously installed version.
 
42
 
 
43
.. i18n: The tables are rebuilt from the current module definitions. To rebuild the
 
44
.. i18n: tables, the server uses the definition of the objects and adds / modifies
 
45
.. i18n: database fields as necessary.
 
46
..
 
47
 
 
48
The tables are rebuilt from the current module definitions. To rebuild the
 
49
tables, the server uses the definition of the objects and adds / modifies
 
50
database fields as necessary.
 
51
 
 
52
.. i18n: To invoke a database upgrade after installing a new verion, you need to start
 
53
.. i18n: the server with the **--update=all** argument :
 
54
..
 
55
 
 
56
To invoke a database upgrade after installing a new verion, you need to start
 
57
the server with the **--update=all** argument :
 
58
 
 
59
.. i18n: ::
 
60
.. i18n: 
 
61
.. i18n:        openerp-server.py --update=all
 
62
..
 
63
 
 
64
::
 
65
 
 
66
        openerp-server.py --update=all
 
67
 
 
68
.. i18n: You can also only upgrade specific modules, for example:
 
69
..
 
70
 
 
71
You can also only upgrade specific modules, for example:
 
72
 
 
73
.. i18n: ::
 
74
.. i18n: 
 
75
.. i18n:        openerp-server.py --update=account,base
 
76
..
 
77
 
 
78
::
 
79
 
 
80
        openerp-server.py --update=account,base
 
81
 
 
82
.. i18n: The database is rebuilt according to information provided in XML files and
 
83
.. i18n: Python Classes.
 
84
.. i18n: You can also execute the server with **--init=all**. The server will then
 
85
.. i18n: rebuild the database according to the existing XML files on the system, delete
 
86
.. i18n: all existing data and return OpenERP to its basic configuration.
 
87
..
 
88
 
 
89
The database is rebuilt according to information provided in XML files and
 
90
Python Classes.
 
91
You can also execute the server with **--init=all**. The server will then
 
92
rebuild the database according to the existing XML files on the system, delete
 
93
all existing data and return OpenERP to its basic configuration.
 
94
 
 
95
.. i18n: Detailed update operations
 
96
.. i18n: ++++++++++++++++++++++++++
 
97
..
 
98
 
 
99
Detailed update operations
 
100
++++++++++++++++++++++++++
 
101
 
 
102
.. i18n: OpenERP has a built-in migration and upgrade system which allows updates to be nearly (or often) automatic.
 
103
.. i18n: This system also allows to easily include custom modules.
 
104
..
 
105
 
 
106
OpenERP has a built-in migration and upgrade system which allows updates to be nearly (or often) automatic.
 
107
This system also allows to easily include custom modules.
 
108
 
 
109
.. i18n: Table/Object structure
 
110
.. i18n: """"""""""""""""""""""
 
111
..
 
112
 
 
113
Table/Object structure
 
114
""""""""""""""""""""""
 
115
 
 
116
.. i18n: When you run openerp-server with option ``--init`` or ``--update``, the table 
 
117
.. i18n: structure is updated to match the new description that is in Python code. Fields 
 
118
.. i18n: that are removed from Python code are not removed from the postgresql database 
 
119
.. i18n: to avoid losing data.
 
120
..
 
121
 
 
122
When you run openerp-server with option ``--init`` or ``--update``, the table 
 
123
structure is updated to match the new description that is in Python code. Fields 
 
124
that are removed from Python code are not removed from the postgresql database 
 
125
to avoid losing data.
 
126
 
 
127
.. i18n: So, simply running with ``--update`` or ``--init``, will upgrade your table structure.
 
128
..
 
129
 
 
130
So, simply running with ``--update`` or ``--init``, will upgrade your table structure.
 
131
 
 
132
.. i18n: It's important to run ``--init=module`` the first time you install the module. 
 
133
.. i18n: Next time, you must use the ``--update=module`` argument instead of the init 
 
134
.. i18n: one. This is because ``--init`` loads resources that are loaded only once and 
 
135
.. i18n: never upgraded (i.e., resources with no ``id=""`` attribute or within a 
 
136
.. i18n: ``<data noupdate="1">`` tag). The ``noupdate`` attribute can be overridden by
 
137
.. i18n: marking a record with ``forcecreate="True"``. This means that the record will be
 
138
.. i18n: created if it doesn't already exist in the database, but it won't be modified.
 
139
..
 
140
 
 
141
It's important to run ``--init=module`` the first time you install the module. 
 
142
Next time, you must use the ``--update=module`` argument instead of the init 
 
143
one. This is because ``--init`` loads resources that are loaded only once and 
 
144
never upgraded (i.e., resources with no ``id=""`` attribute or within a 
 
145
``<data noupdate="1">`` tag). The ``noupdate`` attribute can be overridden by
 
146
marking a record with ``forcecreate="True"``. This means that the record will be
 
147
created if it doesn't already exist in the database, but it won't be modified.
 
148
 
 
149
.. i18n: Data
 
150
.. i18n: """"
 
151
.. i18n: Some data is automatically loaded at the installation of OpenERP:
 
152
..
 
153
 
 
154
Data
 
155
""""
 
156
Some data is automatically loaded at the installation of OpenERP:
 
157
 
 
158
.. i18n:     * views, actions, menus,
 
159
.. i18n:     * workflows,
 
160
.. i18n:     * demo data
 
161
..
 
162
 
 
163
    * views, actions, menus,
 
164
    * workflows,
 
165
    * demo data
 
166
 
 
167
.. i18n: This data is also migrated to a new version if you run --update or --init.
 
168
..
 
169
 
 
170
This data is also migrated to a new version if you run --update or --init.
 
171
 
 
172
.. i18n: Workflows
 
173
.. i18n: """""""""
 
174
..
 
175
 
 
176
Workflows
 
177
"""""""""
 
178
 
 
179
.. i18n: Workflows are also upgraded automatically. If some activities are removed, the documents states evolves automatically to the preceding activities. That ensure that all documents are always in valid states.
 
180
..
 
181
 
 
182
Workflows are also upgraded automatically. If some activities are removed, the documents states evolves automatically to the preceding activities. That ensure that all documents are always in valid states.
 
183
 
 
184
.. i18n: You can freely remove activities in your XML files. If workitems are in this activity, they will evolve to the preceding unlinked activity. And after the activity will be removed.
 
185
..
 
186
 
 
187
You can freely remove activities in your XML files. If workitems are in this activity, they will evolve to the preceding unlinked activity. And after the activity will be removed.
 
188
 
 
189
.. i18n: Things to care about during development
 
190
.. i18n: """""""""""""""""""""""""""""""""""""""
 
191
..
 
192
 
 
193
Things to care about during development
 
194
"""""""""""""""""""""""""""""""""""""""
 
195
 
 
196
.. i18n: Since version 3.0.2 of OpenERP, you can not use twice the same 'id="..."' during resource creation in your XML files, unless they are in two different modules.
 
197
..
 
198
 
 
199
Since version 3.0.2 of OpenERP, you can not use twice the same 'id="..."' during resource creation in your XML files, unless they are in two different modules.
 
200
 
 
201
.. i18n: Resources which don't contain an id are created (and updated) only once; at the installation of the module or when you use the --init argument.
 
202
..
 
203
 
 
204
Resources which don't contain an id are created (and updated) only once; at the installation of the module or when you use the --init argument.
 
205
 
 
206
.. i18n: If a resource has an id and this resource is not present anymore in the next version of the XML file, OpenERP will automatically remove it from the database. If this resource is still present, OpenERP will update the modifications to this resource.
 
207
..
 
208
 
 
209
If a resource has an id and this resource is not present anymore in the next version of the XML file, OpenERP will automatically remove it from the database. If this resource is still present, OpenERP will update the modifications to this resource.
 
210
 
 
211
.. i18n: If you use a new id, the resource will be automatically created at the next update of this module.
 
212
..
 
213
 
 
214
If you use a new id, the resource will be automatically created at the next update of this module.
 
215
 
 
216
.. i18n: **Use explicit id declaration !**, Example:
 
217
..
 
218
 
 
219
**Use explicit id declaration !**, Example:
 
220
 
 
221
.. i18n:     * view_invoice_form,
 
222
.. i18n:     * view_move_line_tree,
 
223
.. i18n:     * action_invoice_form_open, ...
 
224
..
 
225
 
 
226
    * view_invoice_form,
 
227
    * view_move_line_tree,
 
228
    * action_invoice_form_open, ...
 
229
 
 
230
.. i18n: It is important to put id="...." to all record that are important for the next version migrations. For example, do not forget to put some id="..." on all workflows transitions. This will allows OpenERP to know which transition has been removed and which transition is new or updated.
 
231
..
 
232
 
 
233
It is important to put id="...." to all record that are important for the next version migrations. For example, do not forget to put some id="..." on all workflows transitions. This will allows OpenERP to know which transition has been removed and which transition is new or updated.
 
234
 
 
235
.. i18n: Custom modules
 
236
.. i18n: """"""""""""""
 
237
..
 
238
 
 
239
Custom modules
 
240
""""""""""""""
 
241
 
 
242
.. i18n: For example, if you want to override the view of an object named 'invoice_form' in your xml file (id="invoice_form"). All you have to do is redefine this view in your custom module with the same id. You can prefix ids with the name of the module to reference an id defined in another module.
 
243
..
 
244
 
 
245
For example, if you want to override the view of an object named 'invoice_form' in your xml file (id="invoice_form"). All you have to do is redefine this view in your custom module with the same id. You can prefix ids with the name of the module to reference an id defined in another module.
 
246
 
 
247
.. i18n: Example:
 
248
..
 
249
 
 
250
Example:
 
251
 
 
252
.. i18n:     <record model="ir.ui.view" id="account.invoice_form">
 
253
.. i18n:     ...
 
254
.. i18n:     <record>
 
255
..
 
256
 
 
257
    <record model="ir.ui.view" id="account.invoice_form">
 
258
    ...
 
259
    <record>
 
260
 
 
261
.. i18n: This will override the invoice form view. You do not have to delete the old view, like in 3.0 versions of OpenERP.
 
262
..
 
263
 
 
264
This will override the invoice form view. You do not have to delete the old view, like in 3.0 versions of OpenERP.
 
265
 
 
266
.. i18n: Note that it is often better to use view inheritance instead of overwriting views.
 
267
..
 
268
 
 
269
Note that it is often better to use view inheritance instead of overwriting views.
 
270
 
 
271
.. i18n: In this migration system, you do not have to delete any resource. The migration system will detect if it is an update or a delete using id="..." attributes. This is important to preserve references duing migrations.
 
272
..
 
273
 
 
274
In this migration system, you do not have to delete any resource. The migration system will detect if it is an update or a delete using id="..." attributes. This is important to preserve references duing migrations.
 
275
 
 
276
.. i18n: Demo data
 
277
.. i18n: """"""""""
 
278
..
 
279
 
 
280
Demo data
 
281
""""""""""
 
282
 
 
283
.. i18n: Demo data do not have to be upgraded; because they are probably modified or 
 
284
.. i18n: deleted by users. So, to avoid demo data to be upgraded, you can put a 
 
285
.. i18n: ``noupdate="1"`` attribute in the ``<data>`` tag of your .xml data files.
 
286
..
 
287
 
 
288
Demo data do not have to be upgraded; because they are probably modified or 
 
289
deleted by users. So, to avoid demo data to be upgraded, you can put a 
 
290
``noupdate="1"`` attribute in the ``<data>`` tag of your .xml data files.
 
291
 
 
292
.. i18n: Summary of update and init process
 
293
.. i18n: ++++++++++++++++++++++++++++++++++
 
294
..
 
295
 
 
296
Summary of update and init process
 
297
++++++++++++++++++++++++++++++++++
 
298
 
 
299
.. i18n: init:
 
300
..
 
301
 
 
302
init:
 
303
 
 
304
.. i18n:     modify/add/delete demo data and built-in data
 
305
..
 
306
 
 
307
    modify/add/delete demo data and built-in data
 
308
 
 
309
.. i18n: update:
 
310
..
 
311
 
 
312
update:
 
313
 
 
314
.. i18n:     modify/add/delete non demo data
 
315
..
 
316
 
 
317
    modify/add/delete non demo data
 
318
 
 
319
.. i18n: Examples of built-in (non demo) data:
 
320
..
 
321
 
 
322
Examples of built-in (non demo) data:
 
323
 
 
324
.. i18n:     * Menu structure,
 
325
.. i18n:     * View definition,
 
326
.. i18n:     * Workflow description, ...
 
327
.. i18n:     * Everything that has an `id` attribute in the XML data declaration (if no attr noupdate="1" in the header)
 
328
..
 
329
 
 
330
    * Menu structure,
 
331
    * View definition,
 
332
    * Workflow description, ...
 
333
    * Everything that has an `id` attribute in the XML data declaration (if no attr noupdate="1" in the header)
 
334
 
 
335
.. i18n: What's going on during the update process:
 
336
..
 
337
 
 
338
What's going on during the update process:
 
339
 
 
340
.. i18n:    1. If you manually added data within the client:
 
341
.. i18n:           * the update process will not change them
 
342
.. i18n:    2. If you dropped data:
 
343
.. i18n:           * if it was demo data, the update process will do nothing
 
344
.. i18n:           * it it was built-in data (like a view), the update process will recreate it
 
345
.. i18n:    3. If you modified data (either in the .XML or the client):
 
346
.. i18n:           * if it's demo data: nothing
 
347
.. i18n:           * if it's built-in data, data are updated
 
348
.. i18n:    4. If built-in data have been deleted in the .XML file:
 
349
.. i18n:           * this data will be deleted in the database.
 
350
..
 
351
 
 
352
   1. If you manually added data within the client:
 
353
          * the update process will not change them
 
354
   2. If you dropped data:
 
355
          * if it was demo data, the update process will do nothing
 
356
          * it it was built-in data (like a view), the update process will recreate it
 
357
   3. If you modified data (either in the .XML or the client):
 
358
          * if it's demo data: nothing
 
359
          * if it's built-in data, data are updated
 
360
   4. If built-in data have been deleted in the .XML file:
 
361
          * this data will be deleted in the database.