Chapter 4: Models And Basic Fields
At the end of the previous chapter, we were able to create an Odoo module. However, at this point it is still an empty shell which doesn’t allow us to store any data. In our real estate module, we want to store the information related to the properties (name, description, price, living area…) in a database. The Odoo framework provides tools to facilitate database interactions.
Before moving forward in the exercise, make sure the
estate module is installed, i.e. it must appear as ‘Installed’ in the Apps list.
Reference: the documentation related to this topic can be found in the Models API.
Business objects are declared as Python classes extending
Model, which integrates them into the automated persistence system.
Models can be configured by setting attributes in their definition. The most important attribute is
_name, which is required and defines the name for the model in the Odoo system. Here is a minimum definition of a model:
This definition is enough for the ORM to generate a database table named
. in the model
_name is automatically converted into a
_ by the ORM. By convention all models are located in a
models directory and each model is defined in its own Python file.
Take a look at how the
crm_recurring_plan table is defined and how the corresponding Python file is imported:
The model is defined in the file
crm_recurring_plan.pyis imported in
modelsis imported in
Any modification of the Python files requires a restart of the Odoo server. When we restart the server, we will add the parameters
-u estate means we want to upgrade the
estate module, i.e. the ORM will apply database schema changes. In this case it creates a new table.
-d rd-demo means that the upgrade should be performed on the
-u should always be used in combination with
During the startup you should see the following warnings:
If this is the case, then you should be good! To be sure, double check with
psql as demonstrated in the Goal.
Reference: the documentation related to this topic can be found in the Fields API.
Fields are used to define what the model can store and where they are stored. Fields are defined as attributes in the model class:
name field is a
Char which will be represented as a Python unicode
str and a SQL
There are two broad categories of fields: ‘simple’ fields, which are atomic values stored directly in the model’s table, and ‘relational’ fields, which link records (of the same or different models).
When the fields are added to the model, restart the server with
psql and check the structure of the table
estate_property. You’ll notice that a couple of extra fields were also added to the table. We will revisit them later.
Much like the model itself, fields can be configured by passing configuration attributes as parameters:
Some attributes are available on all fields, here are the most common ones:
str, default: field’s name)
The label of the field in UI (visible by users).
True, the field can not be empty. It must either have a default value or always be given a value when creating a record.
Provides long-form help tooltip for users in the UI.
Requests that Odoo create a database index on the column.
Reference: the documentation related to this topic can be found in Automatic fields.
You may have noticed your model has a few fields you never defined. Odoo creates a few fields in all models1. These fields are managed by the system and can’t be written to, but they can be read if useful or necessary:
The unique identifier for a record of the model.
Creation date of the record.
User who created the record.
Last modification date of the record.
User who last modified the record.
Now that we have created our first model, let’s add some security!