A model holds data, and often there are rules about what data is genuinely valid. Constraints enforce those rules. This piece is about SQL and Python constraints in Odoo.
What a constraint is
A constraint, in Odoo, is an enforced rule about what data is valid. There are often rules about a kind of record's data, conditions the data must genuinely satisfy to be valid, and a constraint is how such a rule is genuinely enforced: a constraint ensures that a record cannot hold data that breaks the rule. The constraint is the difference between a rule that is merely intended and a rule that is genuinely enforced, so that invalid data is genuinely prevented.
Why constraints matter
Constraints matter because data that breaks the genuine rules is bad data, and bad data in the system causes problems. If a rule about valid data is merely intended but not enforced, then, sooner or later, data that breaks it gets in, by mistake, by an oversight, and the system holds invalid data. A constraint genuinely prevents that: the rule is enforced, so the invalid data simply cannot be saved. Constraints are how a developer ensures that the genuine rules about valid data are genuinely kept, so the system's data stays valid.
The two kinds: SQL and Python constraints
Odoo has two kinds of constraint, SQL constraints and Python constraints, and they suit different kinds of rule. An SQL constraint is enforced at the database level, and it suits rules that are simple enough to be expressed and enforced there, straightforward conditions about the data. A Python constraint is enforced through Python code, and it suits rules that are more involved, rules whose checking genuinely needs the logic that code allows, beyond what a simple database-level condition can express. So the two kinds are for two kinds of rule: SQL constraints for the simple, straightforward rules, Python constraints for the more involved ones that need genuine logic to check.
Choosing which kind
The practical point for a developer is to use the kind of constraint that suits the rule. For a simple, straightforward rule about the data, an SQL constraint, enforced efficiently at the database level. For a rule that is more involved, that genuinely needs logic to check, a Python constraint. A developer enforcing a rule should consider whether it is a simple rule, suiting an SQL constraint, or an involved one, needing a Python constraint, and use the kind that genuinely fits. The point, with either kind, is that the genuine rule is genuinely enforced, so invalid data is prevented.
The takeaway
SQL and Python constraints in Odoo enforce rules about what data is valid, so a record cannot hold data that breaks those rules. Constraints matter because they turn an intended rule into an enforced one, genuinely preventing the bad data that an unenforced rule eventually lets in. Odoo has two kinds: SQL constraints, enforced at the database level, for simple, straightforward rules, and Python constraints, enforced through code, for more involved rules that need genuine logic to check. A developer should use the kind that genuinely suits the rule. For how we approach Odoo, see our ERP practice.