It is useful to understand the several layers involved in the Odoo architecture, and the role of each type of component we will use. So we will have a pragmatic overview of the Odoo application architecture, with a focus on helping application development by decomposing work into several components.
Also, Odoo publishes two different product editions, community and enterprise, and regularly releases new versions for both. It is important to understand the differences we can expect between the editions, and what a new major release can mean for our development and deployment. For this, we have an overview of the differences between CE and EE, and on the Odoo major version stability policy.
Let's start looking at the Odoo application architecture.
Odoo follows a multi-tier architecture, and we can identify three main tiers—data, logic, and presentation:
The Data Tier is the lowest-level layer, and is responsible for data storage and persistence. Odoo relies on a PostgreSQL server for this. PostgreSQL is the only supported database server, and this is a design choice. So, other databases such as MySQL are not supported. Binary files, such as attachments of documents or images, are usually stored in the filesystem, in a directory referred to as the filestore.
Note
This means that a full backup of an Odoo instance needs both a database dump and a copy of the filestore.
The Logic Tier is responsible for all the interactions with the data layer, and is handled by the Odoo server. As a general rule, the low-level database should only be accessed by this layer, since it is the only way to ensure security access control and data consistency. At the core of the Odoo server, we have the object-relational mapping (ORM) engine for this interface. The ORM provides the application programming interface (API) used by the add-on modules to interact with the data.
For example, the partner data entity, such as a customer or a supplier, is represented in the ORM by a model. This model is a Python object class supporting several interaction methods, such as create() to create new partner records, or read() to query existing records and their data. These generic methods can implement specific business logic in particular models. For example, the create() method might implement default values or enforce validation rules; the read() method might support some automatically computed fields, or enforce access controls depending on the user performing that action.
The Presentation Tier is responsible for presenting data and interacting with the user. It is implemented by a client responsible for all the user experience. The client interacts with the ORM API to read, write, verify, or perform any other action, calling ORM API methods through remote procedure calls (RPCs). These are sent to the Odoo server for processing, and then the results are sent back to the client for further handling.
For the Presentation Tier, Odoo provides a full-featured web client out of the box. The web client supports all the features needed by a business application: login sessions, navigation menus, data lists, forms, and so on. The global look and feel are not as customizable as a frontend developer might expect, but it makes it easy to create a functional and consistent user experience.
A complementary presentation layer includes the website framework. It gives full flexibility to create web pages with the exact user interface intended, like in other CMS frameworks, at the expense of some additional effort and web expertise. The website framework supports web controllers to implement code for presenting specific logic, keeping it separate from the model's intrinsic logic. Frontend developers will probably feel very much at home in this space.
The Odoo server API is very open, and all server functions are available through it. The server API used by the official web client is the same as the one available to any other application. So, other client implementations are possible, and could be built in almost any platform or programming language. Desktop and smartphone applications can be built to provide specific user interfaces, leveraging the Odoo data and logic tiers for business logic and data persistence.
Odoo is the name of the software product, and also the name of the company that builds it. Odoo follows an open core business model, where the community edition (CE) is free and open source, and the enterprise edition (EE) is a paid product, providing income for the company.
The CE provides all the framework features plus the essential features for most of the business applications bundled with Odoo. It is licensed under an LGPL license, chosen to allow adding proprietary extensions on top of open source modules.
The EE is built on top of the CE, providing all its features plus some additional exclusive ones. Notably, it includes an improved and mobile-friendly user interface, although the user interface underlying the organization is essentially the same in both editions.
The Odoo online SaaS service uses Odoo enterprise, and may have deployed intermediate versions released after the latest Odoo enterprise major version.
At the time of writing, Odoo's latest stable version is version 12, marked on GitHub as branch 12.0. This is the version we will work with throughout the book. In recent years, major stable versions have been released on a yearly schedule, in October, at the annual Odoo experience conference.
The last three stable versions are supported. With the release of 12.0, versions 11.0 and 10.0 are still supported, and version 9.0 stopped being supported. This means it will stop receiving bug and security fixes.
It's important to note that Odoo databases are incompatible between Odoo major versions. If you run an Odoo 11 server against a database created for a previous major version of Odoo, it won't work. Non-trivial migration work is needed before a database can be used with a later version of the product.
The same is true for add-on modules: as a general rule, an add-on module developed for an Odoo major version will not work on other versions. When downloading a community module from the web, make sure it targets the Odoo version you are using.
On the other hand, major releases (10.0, 11.0) are expected to receive frequent updates, but these should be mostly bug fixes. They are assured to be API-stable, meaning that model data structures and view element identifiers will remain stable. This is important because it means there will be no risk of custom modules breaking due to incompatible changes in the upstream core modules.
The version in the master branch will result in the next major stable version, but until then, it's not API-stable and you should not use it to build custom modules. Doing so is like moving on quicksand—you can't be sure when some changes will be introduced that will break your custom module.