# OpenUpgrade API: giao diện cho các file phân tích của OpenUpgrade

> File phân tích của OpenUpgrade liệt kê mọi model, trường và module đã đổi giữa các phiên bản Odoo. Một API và một trang web giúp tra cứu chúng, kèm YAML cho odoo-module-migrator.

**Date:** 2025-09-10
**Source:** <https://trobz.com/vi/insights/openupgrade-api-ui-for-openupgrade-analysis-files/>

---


{{< img src="/images/insights/openupgrade-api-ui-for-openupgrade-analysis-files/OpenUpgrade_Explorer.png" alt="OpenUpgrade Explorer" >}}

## Giới thiệu [OpenUpgrade](https://github.com/oca/openupgrade): nền móng của việc nâng cấp Odoo

[OpenUpgrade](https://github.com/oca/openupgrade) là một dự án mã nguồn mở quan trọng của Odoo Community Association (OCA). Mục đích chính của nó là cung cấp các script để nâng cấp database qua các phiên bản lớn của Odoo (ví dụ từ 17.0 lên 18.0).

Trong quá trình đó, [OpenUpgrade](https://github.com/oca/openupgrade) sinh ra hai file log rất giá trị:

- **upgrade_analysis.txt** ([ví dụ](https://github.com/OCA/OpenUpgrade/blob/18.0/openupgrade_scripts/scripts/account/18.0.1.3/upgrade_analysis.txt)): file này chứa danh sách chi tiết các thay đổi phá vỡ tương thích ngược giữa hai phiên bản, gồm các model, trường và bản ghi XML đã được thêm, gỡ bỏ hoặc đổi tên.
- **apriori.py** ([ví dụ](https://github.com/OCA/OpenUpgrade/blob/18.0/openupgrade_scripts/apriori.py)): file này chứa danh sách chi tiết các thay đổi ở cấp module, bao gồm những trường hợp sau:
  - **Module đổi tên**: khi tên kỹ thuật của một module thay đổi giữa các phiên bản (ví dụ note được đổi thành project_todo)
  - **Module bị gộp**: khi một module được gộp vào một module khác
  - **Không cần nữa**: một số module đã được thu vào các tính năng gốc của Odoo trong quá trình phát triển
  - **Module chuyển chỗ**: một số module được chuyển sang repository khác. Ví dụ, module ed_oca chuyển từ _OCA/edi_ sang _OCA/edi-framework_ giữa _15.0_ và _16.0_.

Chúng tôi tin những thông tin trên rất hữu ích khi làm việc với Odoo. Vì vậy, chúng tôi quyết định phân tích các file này thành nhiều database có cấu trúc, để dữ liệu truy vấn được dễ dàng qua một API và duyệt được bằng một giao diện người dùng.

## Một giao diện để duyệt các file phân tích dễ hơn

[OpenUpgrade API](https://github.com/trobz/openupgrade-api) chuẩn hóa toàn bộ luồng xử lý dữ liệu (**ETL**: **E**xtract – **T**ransform – **L**oad) cho các thay đổi khi nâng cấp, rồi phơi chúng ra qua một **REST API** tiện dụng. Nó hoạt động như sau:

1. **Extract**: tự động kéo mọi script nâng cấp thẳng từ các nhánh của [OpenUpgrade](https://github.com/oca/openupgrade) (ví dụ _16.0_, _17.0_, _18.0_).
2. **Transform**: phân tích và "dịch" phần văn bản thô trong các file upgrade_analysis.txt ([ví dụ](https://github.com/OCA/OpenUpgrade/blob/18.0/openupgrade_scripts/scripts/account/18.0.1.3/upgrade_analysis.txt)) thành một cấu trúc dữ liệu sạch và thống nhất (ChangeRecord).
3. **Load**: lưu dữ liệu đã chuẩn hóa vào một database SQLite, tách bạch rõ theo từng phiên bản lớn (ví dụ 16.0, 17.0, 18.0). Mỗi file DB là một ảnh chụp độc lập.
4. **API**: cung cấp các endpoint để bạn dễ dàng truy vấn dữ liệu thay đổi theo **module**, **model** và **phiên bản**.

Các mục tiêu chính của [OpenUpgrade API](https://github.com/trobz/openupgrade-api) là:

- Gom về một mối và chuẩn hóa mọi phát hiện từ [OpenUpgrade](https://github.com/oca/openupgrade) thành một nguồn duy nhất, dễ truy vấn.
- Cung cấp một REST API để lập trình viên và chuyên viên tư vấn tra cứu nhanh các thay đổi khi lập kế hoạch chuyển đổi.
- Tự động sinh các file YAML tương thích với [Odoo Module Migrator](https://github.com/OCA/odoo-module-migrator) để tự động hóa các thao tác **đổi tên** và **gỡ bỏ**.
- Làm backend cho các công cụ của cộng đồng, chẳng hạn cổng tra cứu [openupgrade.trobz.com](http://openupgrade.trobz.com).

## Nâng mức tự động hóa cùng [Odoo Module Migrator](https://github.com/OCA/odoo-module-migrator)

Đây là tính năng mạnh nhất! [OpenUpgrade API](https://github.com/trobz/openupgrade-api) tự sinh được các file YAML mà [Odoo Module Migrator](https://github.com/OCA/odoo-module-migrator) hiểu được. Bạn tạo các file này bằng lệnh **get**:

- Lấy danh sách các model bị gỡ bỏ ở phiên bản 18.0: `python manage.py get --object-type removed --object models --versions 18.0 --output-directory output`
- Lấy danh sách các trường bị gỡ bỏ ở phiên bản 18.0: `python manage.py get --object-type removed --object fields --versions 18.0 --output-directory output`
- Tương tự với model và trường đã đổi tên: `python manage.py get --object-type renamed --object models --versions 18.0 --output-directory output` và `python manage.py get --object-type renamed --object fields --versions 18.0 --output-directory output`

Các file YAML sẽ được sinh ra trong thư mục output với cấu trúc rõ ràng. Việc bạn phải làm chỉ là:

1. Sinh các **file YAML** cho phiên bản bạn đang chuyển đổi tới (ví dụ 17.0 → 18.0).
2. **Chép** các file đó vào repository chuyển đổi của bạn.
3. **Chạy odoo-module-migrator**, và nó sẽ tự áp dụng các thay đổi dựa trên dữ liệu bạn cung cấp.

## Giao diện web: [openupgrade.trobz.com](http://openupgrade.trobz.com/)

Để bổ trợ cho [OpenUpgrade API](https://github.com/trobz/openupgrade-api), chúng tôi làm [OpenUpgrade Explorer](http://openupgrade.trobz.com), một giao diện web gọn gàng và thân thiện, giúp dữ liệu chuyển đổi đã được cấu trúc trở nên dễ tiếp cận. Nó giúp lập trình viên và chuyên viên tư vấn đi nhanh qua các thay đổi phá vỡ tương thích ngược và các thay đổi ở cấp module, mà không phải vật lộn trực tiếp với API hay log thô.

Với nó, bạn có thể:

- Soi nhanh các thay đổi theo **module**/**model**/**trường** qua các phiên bản Odoo.
- Kiểm chứng các thao tác quan trọng như **đổi tên**/**gỡ bỏ**/**gộp**/**lỗi thời**/**chuyển chỗ** trước khi lập kế hoạch chuyển đổi.
- Chia sẻ đường dẫn tra cứu với đội của bạn hoặc với khách hàng.

Xem thử tại: [openupgrade.trobz.com](https://openupgrade.trobz.com/)