The first step has a database constraint created on the model's table. It is enforced at the database level. The _sql_constraints model attribute accepts a list of constraints to create. Each constraint is defined by a three-element tuple; they are listed as follows:

• A suffix to use for the constraint identifier. In our example, we used name_uniq, and the resulting constraint name is library_book_name_uniq.
• The SQL to use in the PostgreSQL instruction to alter or create the database table.
• A message to report to the user when the constraint is violated.

As mentioned earlier, other database table constraints can be used. Note that column constraints, such as NOT NULL, can't be added this way. For more information on PostgreSQL constraints in general and table constraints in particular, take a look
at http://www.postgresql.org/docs/current/static/ddl-constraints.html.

In the second step, we added a method to perform Python code validation. It is decorated with @api.constrains, meaning that it should be executed to run checks when one of the fields in the argument list is changed. If the check fails, a ValidationError exception will be raised.