Odoo. Миграции

Question

У меня есть некоторые модули, которые расширяют дополнения Odoo. Например, модели в my_module которые расширяют : 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 

Такая же ситуация для модулей, которые расширяют час, продукт и т.д. мне нужно внести некоторые изменения в модели. Например, в my_module_1 Мне нужно изменить пару полей (тип, отношение), в my_module_2 просто удалить несколько полей и т. Д. Конечно, мне также нужно изменить представления каждого модуля. И, конечно же, у меня есть собственные модели, которые имеют зависимости от моделей из разных приложений/модулей. Но у меня есть данные о производстве, которые необходимо хранить. Я не нашел никакой информации о миграции (или синхронизации модулей) в Odoo.

Мой вопрос: Каков наилучший способ обновления модулей/приложений на производстве (если у нас много изменений в полях моделей и просмотров)? Заранее спасибо.

Answer 1

Сначала вы должны сбросить производственную базу данных и затем восстановить ее в своей локальной системе.

После восстановления в локальной системе разработайте свои пользовательские модули, чтобы расширить существующие функции модели.

Установите разработанные модули в локальной системе (восстановленная база данных) и просмотрите сделанные вами изменения. Если все отлично с существующими данными, то установите этот модуль в производственную базу данных.

Чтобы сбросить базу данных производства, выполните следующую команду в postgres. Команда: pg_dump имя_бд> выходной_файл Пример: pg_dump prod_db> prod_db.sql

Перед восстановлением базы данных, необходимо создать свежую базу данных в локальной системе. Для создания свежей базы данных выполнить следующую команду, команду: CREATEDB --owner owner_name --encoding UTF-8 имя_бд Пример: CREATEDB --owner odoo --encoding UTF-8 prod_db

Для восстановления производственной базы данных выполните ниже команды в postgres. Команда: PSQL имя_бд < входной_файл путь Пример: pg_dump prod_db> prod_db.sql

Answer 2

Может быть, есть некоторые инструменты для миграции в Odoo предприятия версии, но я не нашел никакой информации об этом. Поэтому решение, которое я использую, - это делать все вручную. Шаг за шагом, внимательно. Если вы знаете лучший способ, дайте мне знать.

Например. Если нам нужно удалить некоторые поля:

1. Удалить поля из моделей и просмотров в вашем модуле/приложении.
2. Остановить openerp-сервер. Запустите sql, который отбрасывает наши столбцы.
3. Разверните новые версии моделей и представления на сервере. Запустить openerp-сервер.
4. режим разработчика Activate -> Перейти к настройкам -> найти ваш модуль/приложение -> нажмите кнопку Update (Обновление)

Если вам необходимо изменить тип/отношение полей:

1. Добавьте поле (с новым типом/отношением) к вашей модели.
2. Подготовить скрипт sql, который будет передавать данные из старого столбца в новый столбец/таблицы.
3. Удалите старое поле с вашей модели и просмотров.
4. Остановить openerp-сервер. Запустите sql-скрипт, оставьте старые столбцы.
5. Разверните новые версии моделей и представления на сервере. Запустить openerp-сервер.
6. режим разработчика Activate -> Перейти к настройкам -> найдите ваш модуль/приложение -> нажмите Update (Обновление)

Будьте осторожны при изменении соотношения (one2many, many2many). Сделайте дампы и версии приложений. Несколько раз проверяйте свои модификации на локальном компьютере с db из производства.

Еще одна вещь о новых полях с отношениями. Например, у меня есть module_1 который зависит от crm. module_2, которая зависит от module_1 и т.д. Мне нужно добавить несколько полей для УРК моделей и показать их в module_1. В module_2 Мне нужно показать новые поля из моих собственных моделей в module_1.

Мы можем добавить все новые поля к моделям и представлениям в наших модулях. Остановите сервер и запустить сервер с параметром --update так:

./openerp-server --update=all 

В этом случае все модули будут обновлены. Если нам нужно обновить только модули, которые зависят от CRM нам нужно просто обновить : CRM

./openerp-server --update=crm 

Answer 3

Перезапустите сервер из командной строки один раз с -u и -d флагов например.

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

Если вы имеете дело с сервером производства, я бы проверить это локально, на вашей машине с новой свалки производства DB убедитесь, что он работает, настроить его, если это необходимо (например, некоторые поля, возможно, потребуется по умолчанию, независимо), повторите проверку еще раз на новом дампе до тех пор, пока все, что мне нужно сделать, это перезагрузить сервер, как указано выше, чтобы произошли изменения. Как только это произойдет, создайте резервную копию базы данных, хранилища данных и даже затронутых модулей на рабочем сервере, загрузите новый модуль (модули) и перезапустите производственный сервер, как указано выше (без демпинга баз данных от теста до производства здесь) обновление модуля должно уход за изменениями базы данных.

Если вы пытаетесь существенно изменить структуру таблицы (например, изменить тип данных полей) и сохранить данные в таблицах, единственный способ, которым я могу это сделать, - создать новые поля сначала с новым типом данных, заполнить их с данными из старых полей (либо напрямую с запросами postgres, либо внутри вашего «промежуточного модуля версии»), и это действительно зависит от изменений, изменение от выбора до many2one включает в себя вставку значений выбора в новую таблицу, две очень разные вещи из точка базы данных, фактический тип поля в таблице будет целым числом, идентификатор из строки, которая содержит значение выбора в реляционной таблице ...

После того, как ваши новые поля заполнены, сделайте окончательную версию модуль, удаляющий все поля, которые вы больше не нужны (сохраните другую версию для производственной базы данных).

Я бы, вероятно, проверил популяцию базы данных вручную на сервере разработки сначала либо в postgres, либо с помощью какого-либо инструмента, такого как pgadminIII, но планировал создать сценарий для его создания на производственном сервере (или, еще лучше, создать его в новом версия модуля), поскольку это должно быть уменьшено, пока это произойдет.

Я также посмотрел бы на мои таблицы postgres после того, как все будет готово, некоторые поля все еще могут быть там, даже если новый модуль их не использует.

К сожалению, я не знаю ни одного более простой, автоматический способ сделать это, там просто слишком много переменных ...

Answer 4

По вашему примеру, я считаю, что вы уже знаете, как добавить новое поле к существующей модели.

Я до сих пор не понимаю, почему кто-то захочет удалить поле из существующей модели - это будет больше проблем, чем это стоит (если есть веская причина, сообщите мне). Это также применяется при попытке изменить типы полей. С учетом этого вы можете легко удалить/заменить/скрыть существующее поле на представлении, что, по сути, должно достичь того же результата.

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> 

Вы также говорили о переносе данных из иждивенцев на другую модель с помощью копирования/вставки. Это не требуется, поскольку вы можете просто получить доступ к данным в существующей модели с помощью ссылки на прямой объект/поле или с помощью связанного поля.

related field on odoo?

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

Я не буду ничего общего с установкой боковых команд модуля/сервер, как и другие ответы здесь уже рассматривали эти аспекты решения.