ObjectID

[sebastienbeau]

For historical reason we have an "ObjectID" field in the index (algolia specific need)

• "ObjectID" = id of the odoo record (this was used by aloglia as key for update*)

• "id" = id of the binding

• we choose as key for the index the id of the record so if you delete and recreate a binding the id is always the same in the index and if something goes really wrong as it's the same id an update will still work

For front end dev having the id and objectID is confusing

So I propose

• "ObjectID" = id of the odoo record "and make it deprecated" (remove this in V15 or V16 for example)
• "id" = id of the odoo record and use it

@thibaultrey @simahawk

[thibaultrey]

Ahhh great initiative, it's time to tackle this issue. So if I understand correctly, in a first step, depreciate objectId and Id would have the same value right kthe record id) ?

Do we have some api action who accepts only binding ID in parameters for now ?

[sebastienbeau]

We do not have api that use the "binding id" so we can remove it and then put the value of "objectID" into the key "id"

[simahawk]

• in search engine _record_id_key should be set to id by default and we should include _record_id_key automatically (right now id is added but that could be wrong or useless, for algolia at least)
• here, we should remove completely id and/or objectID from the ir.export record

[simahawk]

* here, we should remove completely `id` and/or `objectID` from the ir.export record

the only drawback of this would be that the json stored won't include the external ID but I think it's not a problem. Actually we avoid storing something useless...

[sebastienbeau]

It's ok for me.

• removing the id logic in ir.exports
• adding them automatically in search engine using the _record_id_key

I will do a PR in search engine/elastic/algolia and in shopinvader.

Did I remove totaly the key objectID (this will be a breaking change ? but V14 is a new version so we can add this in the changelog?)

Note for algolia this required field can be added automatically, for algolia case we will have the

• objectID (need to update a record, elastic can take whatever key, algolia need to have this key named objectID)
• id that will be used in the template (for having the best compatibility between elastic and algolia)

[simahawk]

objectID is still required for algolia, no?

[sebastienbeau]

yes, but I will only push it for algolia and set the same value as id. So in the templating we always use the key id (for all search engine) and we only have this extra key objectId that we just do not use in the templating