[16.0] connector_search_engine: add binding hooks to recompute and validate + include update TS

[simahawk]

As for the TS change (last commit) I think is very handy. However, we could include it only on demand (eg: flag on the index record).

Any feedback?

[simahawk]

@lmignon @sebastienbeau gentle ping 😄

[lmignon]

Thank you @simahawk All this makes sense. (Code review)

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[lmignon]

Thinking further, I wonder whether this is really the right approach. The architecture has been designed to allow you to register your own adapters for data serialisation and validation. You should never have to overload the se.binding model to adapt the way the record is serialized and/or validated. To do this you can register your own serializer and validator at index level. Interfaces are provided for these two basic operations and it is the responsibility of the object implementing these interfaces to do so. It seems to me that the PR goes against the proposed approach which aims to separate srialization / validation etc from the binding itself. With you change it's no more possible to use an XML selializer for exemple.

[simahawk]

Thinking further, I wonder whether this is really the right approach. The architecture has been designed to allow you to register your own adapters for data serialisation and validation. You should never have to overload the se.binding model to adapt the way the record is serialized and/or validated. To do this you can register your own serializer and validator at index level. Interfaces are provided for these two basic operations and it is the responsibility of the object implementing these interfaces to do so. It seems to me that the PR goes against the proposed approach which aims to separate srialization / validation etc from the binding itself. With you change it's no more possible to use an XML selializer for exemple.

I understand. I doubt we are going to have an XML serializer but yeah...

My POV: this is pure metadata. It does not belong to serialization itself. It should be there no matter which serializer you use. Yet, the current implementation is broken if you don't get a dict back. I could improve it. Also, we could make this optional via param.

WDYT?

[lmignon]

I understand. I doubt we are going to have an XML serializer but yeah...

In this "architecture" responsabilities are delegate to specialized classes and you are free to register your own classes (for serialization, validation, storage ...) I would like to keep this approach and don't mix responsibilities.

My POV: this is pure metadata. It does not belong to serialization itself. It should be there no matter which serializer you use. Yet, the current implementation is broken if you don't get a dict back. I could improve it. Also, we could make this optional via param.

In my UC I always use pydantic models to validate and serialize data. This approach allows me to provide to developers using the data among other things the schema of these data. If we start to add some metadata attributes, these attributes will not be part of the documentation except if I also declare these attributes into my models...

"We could make it configurable". Why not....

WDYT?

I will not block but I still think it's not the right approach. I have the feeling that we're opening the door to bad practices, but I don't claim to hold the absolute truth. 😏

Don't want to block...