The Rawi Experience

I have seen many Odoo applications with tons over tons of delegated inheritance. Usually, delegated inheritance is not needed and most probably is the wrong design, especially when it comes to just show different types of contacts, res.partner, instead of a single selection field of even one2many field if types are client dependent. Let’s look at why this is a bad design.

Code Complexity

In our example, I came across a Hospital Management System, HMS for short, that offered different types of contacts, as follows:

• Patients
• Doctors
• Medical Staff
• Pets
• Pet Owners

Each one of these used delegated inheritance from res.partner. Each object, or model, required its own views with minimal changes to the basic data, e.g., contact name, gender, date of birth, etc. There was no immediate benefit or added value to this design except for filtration. The original developer did not have to set domains on any many2one fields. Other than that, it was tons of code blocks repeated time after time. Trying to add a single common field, we had to add passport and government ID numbers, required copying and pasting the same field across all and different views.

Database Bloat

Each delegated inheritance adds a new table to the database with additional fields and primary keys linking to the res.partner record, not only increasing the overall size of the database, but also increasing the complexity of its relations.

Performance

When Odoo’s ORM looks up fields in such objects, it looks up its own database table, if the field is not found, it looks up the inherited object’s table. This, as you can imagine, increases the latency. True it can be neglected on small sized client instances, but we had a client with over 100K contacts on the database. You can imagine extracting any reports took forever to load.

Did Odoo use it?

Throughout the most common and official Odoo applications, you will find only account.payment to be delegated from account.move. It is not wrong to use delegated inheritance, but it is wrong to use it mindlessly for minor use cases like the one described here.

The Solution

For this specific case, I removed the delegated inheritances and added all the fields directly to the res.partner model, with a single new selection field to set the type of contact, and removed all the extra views and created a single root view for all HMS apps to use and inherit. While the root view was complex, showing and hiding fields and entire notebook pages, based on contact type, it was a relieve when it comes to writing new code, adding new features and methods.