Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The OpenERP ORM is capable of synchronizing the database schema with the python definition of the models, but it cannot perform complex migration operations. Its purpose is to create or update the database tables and columns necessary to support the newest version of your models, i.e. allow inserting, updating and reading records.</p> <p>As part of this synchronization, it supports simple schema alterations: as long as the name and type of a column does not change, the ORM will try to update the SQL constraints (NOT NULL, UNIQUE, FOREIGN KEY, etc.), and the ONDELETE rule, if any.</p> <p>If the type changed, the old column will be renamed to be out of the way (but kept around so you can manually migrate the data), and a new appropriate column will be created. You'll need a manual migration operation if you want to migrate the data [*].</p> <p>If the only thing that changes is the name of the column, you can give the ORM a hint about that using the <code>oldname</code> column property. It tells the ORM that an old column needs to be renamed instead of creating a new one. For example, this column definition would make the ORM attempt to rename <code>partner_id</code> to <code>customer_id</code> if the <code>customer_id</code> column is missing:</p> <pre><code>'customer_id': fields.many2one('res.partner', 'Customer', oldname='partner_id'), </code></pre> <p>You can start the synchronization logic either by launching the server with <code>`-u &lt;module&gt; -d &lt;database&gt;</code> or by clicking on the "Update" button of the corresponding module in the Settings menu of that database (<code>--update</code> is a synonym of <code>-u</code>, but make sure to pass <code>-d</code> to have it start the synchronization on the database directly).</p> <p>Note that you should not use the <code>oldname</code> parameter when you're in development and just trying out different database schema definitions. This option is mainly useful for keeping track of field renamings between major versions of a given module. For work-in-progress development you don't care about keeping track of all the iterations so using <code>-u</code> is sufficient, you should periodically start again on a new empty database anyway.</p> <hr> <p>[*] There is limited and mostly undocumented support for embedding your own migration scripts in your modules, where the ORM will automatically execute them depending on the detected module version. Unfortunately the best way to understand how this work is to read <a href="http://bazaar.launchpad.net/~openerp/openobject-server/7.0/view/5156/openerp/modules/migration.py#L56" rel="nofollow">the source code</a>.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload