Community: Framework mailing list archives

Re: New API: field names for Many2one and Many2many - shall we postifix with _id?

Pedro M. Baeza
- 09/22/2014 06:38:57
Hi, I agree with Raphäel about the inconsistency found across core code, but there are two different topics here: variable names and field names. Maxim started talking about variables names inside methods. You should use the name without ids, because as you said, new search API returns a RecordSet (collection on browse records), instead of a list on integers.

But a different question is what Raphäel says: field names. Traditionally, a not written rule says that if you name a field with an _id at the end, it means a many2one field, and with _ids, this means many2many or one2many (first incongruency, because you cannot diferentiate both), and this is for distinguishing for regular fields (integer, float, and so on), but as Raphäel points, this rule is not consistent, it's a bad rule because the code is read ery ugly in a lot of cases, so lastly, I'm creating my x2x fields without any suffix, concentrating in the word/words that describes best the field content and with singular/plural form according m2o or m2m/o2m type.


2014-09-21 21:44 GMT+02:00 Raphaël Valyi <>:
Hello Maxim,

it has always been misleading since it has been created sadly...
If in some on_change method, you had:
categ_id -> the id of the category passed in the on_change (via Ajax)
product.categ_id -> the category Browse record category object -> the id of the category if categ isn't null which you had to guard against

At the end, if a developer reads a variable categ_id, he has to figure out himself if that's an id or an object...
So the inconsistency is nothing new sadly and I was raising these question back in 2008 already... May be it's just accentuated now that a variable like categ_id would be even more often an object than an id.

But frankly now that all foreign keys followed that invented convention (and not even consistently, see order_line instead of order_line_ids in a sale order for instance), it looks rather difficult to question this legacy choice and refactor all the code. If that was coded in a static language, may be, but in a dynamic language, re-factoring all the keys in all the codebase looks rather error prone. Juts look how many little regressions you find i the v8 and imagine if all the codebase was refactored (with nobody testing it meanwhile)...
Not to say that in v8 only 10% of the official addons codebase at best uses that new API...

So as for deciding a different convention for new keys, IMHO it will just increase the mess instead of decrease it.

So I would say, we better live with it an accept it's not like shiny Django API. Aren't ERP's a mess anyway?

Also, in the Ooor Ruby connector, in order to better match the Rails API which I think is like Django in the sense that method returning objects don't have and _id(s) suffix, what I did is:
  1. for a many2one, I automatically create an alias that happens an _id suffix no matter what. That means I can have product.categ_id that already exists. But product.categ_id_id is also a valid key that will return under the hood.
  2. for many2many, I create an alias with _ids. So I can have sale_order.order_line_ids that will in fact return the equivalent of [ for line in sale_order.order_line] (but done on the Ruby client side).
So in Ooor code, if I see a key with _id I'm sure it's always an object. If I see _id_id or of course, I'm sure it's always an id. It's ugly but it's consistent...

This allows me to have other Ruby Rails gems that expect the ActiveModel/ActiveRecord API still work with Ooor. Notable examples are simple_form (Twitter Bootstrap forms for Rails), cocoon (nested forms in Rails) or Dragonfly (asset Management) that all work seamlessly with Ooor and Odoo behind.

May be you could use this trick or may be the new API could be extended to have such fields. I'm not sure if Django has _id and _ids shortcuts to ids like Rails though.

Now IMHO, something like OCA peer review processes is exactly the way to proceed in the future to at least avoid increasing the technological debt when having to make new design choices.


On Sun, Sep 21, 2014 at 3:44 PM, Maxim Litnitskiy <> wrote:
Hi guys!
In old api we had to begin any operation with search method which returned ids of records.
So we named the fields accordingly: user_id, user_ids.
But new api does return recordset, so is there any reason to postfix with _id(s)?
Now[('search', '=', 'critaria')]) return not list with ids but objects!
So using _id(s) can be misleading.
New api now is like Django and they do not use _id(s).
What do You thing?


Post to:


Post to: