Danila Ganchar
Danila Ganchar

Reputation: 11223

Odoo Migrations

I have some modules which expand add-ons of Odoo. For example, models in my_module which expand crm:

class Lead(models.Model):
    _inherit = 'crm.lead'
    # exmaple fields
    field_1 = fields.Char(...)
    field_2 = fields.Many2one(...)
    # ... field 99


class Stage(models.Model):
    _inherit = 'crm.stage'
    # exmaple fields
    field_1 = fields.Char(...)
    field_2 = fields.Many2one(...)
    # ... field 99

The same situation is for modules which expand hr, product, etc. I need to make some changes to the models. For example, in my_module_1, I need to change a couple of fields(type, relation), in my_module_2, just to remove a few fields etc. Of course I also need to change views of each module. And of course I have my custom models which have dependencies with models from different apps/modules. But I have data on production which must be stored. I did not find any information about migrations(or synchronization of modules) in Odoo.

My question is: What is the best way to update modules/apps on production(if we have many changes in fields of models and views)? Thanks in advance.

Upvotes: 20

Views: 4913

Answers (5)

gdaramouskas
gdaramouskas

Reputation: 3747

My question is: What is the best way to update modules/apps on production(if we have many changes in fields of models and views)?

While this question has been around for a while I cannot see any canonical answer therefore here are my two cents.

The problem of migration from one version to another in Odoo is rather common and definitely complicated. With that in mind the OpenUpgrade project has been created. OpenUpgrade is basically an upgrade path that will help you transform your data and models from version A to version B. For example if a field named fieldA has had its type changed on version 9 and you are on version 8, OpenUpgrade will take care of this by doing the necessary transformations.

OpenUpgrade also gives you the possibility to create your own migration scripts that will do whatever needs to be done in order for your module to be forward ported (or back ported) in various versions. For the standard modules these scripts have already been written to an extend, but for your own you might need to do some writing.

I suggest that you take a look at the documentation above, this is basically your first stop when we talk about migrations in Odoo.


Upvotes: 2

Danila Ganchar
Danila Ganchar

Reputation: 11223

Maybe there are some tools for migrations in Odoo enterprise version, but I haven't found any information about this. So the solution that I use is to do everything manually. Step by step, attentively. If you know a better way let me know.

For example. If we need to remove some fields:

  1. Remove fields from models and views in your module/app.
  2. Stop openerp-server. Run sql which drop our columns.
  3. Deploy new version models and views to the server. Start openerp-server.
  4. Activate developer mode -> Go to settings -> find your module/app -> click Update(Upgrade)

If you need to change the type/relation of fields:

  1. Add a field(with a new type/relation) to your model.
  2. Prepare the sql script which will transfer data from the old column to the new column/tables.
  3. Remove the old field from your model and views.
  4. Stop openerp-server. Run the sql script, drop old columns.
  5. Deploy new version models and views to the server. Start openerp-server.
  6. Activate developer mode -> Go to settings -> find your module/app -> click Update(Upgrade)

Be careful when you change relations(one2many, many2many). Make dumps and versions of apps. Check your modifications on local machine with db from production for a couple of times.

One more thing about new fields with relations. For example I have module_1 which depends on crm. module_2 which depends on module_1 etc. I need to add some fields to crm models and show them in module_1. In module_2 I need to show new fields from my custom models in module_1.

We can add all the new fields to models and views in our modules. Stop the server and run the server with the parameter --update like this:

./openerp-server --update=all

In this case all the modules will be updated. If we need to update only the modules which depend on crm we need just to update crm:

./openerp-server --update=crm

Upvotes: 0

Palza
Palza

Reputation: 788

As per your example, I believe that you already know how to add a new field to an existing model.

I still do not understand why anyone would want to remove a field from an existing model - this is/will be more trouble than it is worth (if there is a valid reason, please let me know). This also applies when attempting to recast field types. With this said, you can quite easily remove/replace/hide an existing field on a view, which should in essence achieve the same outcome.

https://www.odoo.com/forum/help-1/question/add-remove-fields-to-inherited-custom-module-72945

<record model="ir.ui.view" id="enter_an_id_here">
    <field name="name">some.text.here.form</field>
    <field name="model">crm.lead</field>
    <field name="inherit_id" ref="crm.external_id_here" />
    <field name="arch" type="xml">
        <field name="name" position="after">
            <field name="your_field_name"/>
        </field>
    </field>
</record>

You also talked about migrating data from dependents to another model via copy/paste. This should not be required as you can simply access the data in the existing model through a direct object/field reference, or by using a related field.

related field on odoo?

new_field = fields.Char(string='String', related='product_id.name')
or inside python
value = self.product_id.name

I will not address anything to do with installing the module/server side commands as the other answers here have already addressed these aspects.

Upvotes: 0

Sciallo
Sciallo

Reputation: 53

Restart the server from the command line once with the -u and -d flags eg.

sudo service odoo stop
/path/to/odoo/odoo.py -d <your_db_name> -u custom_module1,custom_module2

If you're dealing with a production server, I would test this locally, on your development machine with a fresh dump of the production DB make sure it works, tweak it if needed (eg some fields might need defaults, whatever), test it again on yet another fresh dump, until the point that all I need to do is restart the server as above to make the changes happen. Once that happens, back up the database, datastore and even the affected modules on the production server, upload the new module(s) and restart the production server as above (no dumping databases from test to production here) the module update should take care of database changes.

If you're trying to change the structure of a table considerably (eg changing fields datatype) and retain data in tables the only way I can think of doing this is to create add NEW fields first with the new datatype, populate them with data from old fields (either directly with postgres queries or within your "interim version module") and this really depends on the changes, a change from selection to many2one involves inserting selection values into a new table, two very different things from the database point of view the actual field type on the table will be a integer, the ID from the row that holds the selection value in a relational table...

Once your new fields are populated, make the final version of the module removing all the fields you no longer need (keep the other version for the production database).

I would probably test the database population manually on the development server first either in postgres or with some tool like pgadminIII, but plan on creating a script for doing it on the production server (or better yet build it all into the new module version) as it will have to be down while that happens.

I would also look at my postgres tables after it's all done, some fields might still be there even if the new module doesn't use them.

Sorry, I don't know of any simpler, more automatic way of doing it, there just is too many variables...

Upvotes: 0

Nilesh Sheliya
Nilesh Sheliya

Reputation: 591

First you have to dump the production database and then restore it in your local system.

Once restored in local system, develop your custom modules to expand the existing model features.

Install the developed modules in local system(restored database) and see the changes you made. If everything is perfect with existing data, then Install that module in production database.

To dump the production database execute the below command in postgres. Command : pg_dump dbname > outfile Example : pg_dump prod_db > prod_db.sql

Before restoring the database, you have to create fresh database in your local system. To create fresh database execute the below command, command : createdb --owner owner_name --encoding utf-8 dbname Example : createdb --owner odoo --encoding utf-8 prod_db

To restore the production database execute the below command in postgres. Command : psql dbname < infile path Example : pg_dump prod_db > prod_db.sql

Upvotes: 0

Related Questions