RFC Add backend version <-> client version

[simahawk]

ATM it's almost impossible to keep track of which version is available on server side and which one is on client side (locomotive).

We need a way to declare this to make easier to provide compatible data whenever we have a change or simply to understand which shopinvader release we are dealing with.

Example: in this case https://github.com/shopinvader/odoo-shopinvader/pull/476 I have to add another entry to schema of the client which might break the export. If we have a way to say on the backend "we use version X" -> the export can take care of adapting data to it.

This is already the case for prestashop and magento connector BTW.

[simahawk]

@lmignon @sebastienbeau I'd like to hear your opinion :)

[lmignon]

@simahawk Even if at first read the idea looks great, I don't know how to put it in place on a practical point of view. For some of our customer, we also export additional config information from odoo to locomotive. I now think I remember that to export the config, we start by loading the document. We therefore have a way of knowing which fields are provided by the schematics in the locomotive for a given site. These info are available into the site mapper.... https://github.com/shopinvader/odoo-shopinvader/blob/12.0/shopinvader_locomotive/component/exporter.py#L42 https://github.com/shopinvader/odoo-shopinvader/blob/12.0/shopinvader_locomotive/component/shopinvader_site_export_mapper.py#L69

[simahawk]

@guewen you've dealt w/ "versions" on connector backends for a while, can you give us your opinion? IMO being able to target specific version w/ the same code base is really handy. For a connector-wide solution I'd like to have something like @mapping(version='x.y.z'). The way it's done on connector-prestashop and alike it's hack-ish but works. For our specific case we could easily achieve it w/ some extra logic (eg: lookup a specific mapper w/ version suffix).

[guewen]

In the new "component-based" connector implementation, I removed the versions backed in the backend, because it was too complex, hardly used and prevented to have a proper inheritance in many ways. You can still do it, but without "framework" support, it has to be part of the implementation. See http://odoo-connector.com/guides/migration_guide.html#backend-versions I wrote once some additional pattern ideas there https://github.com/OCA/connector-magento/issues/275#issuecomment-376866839

[simahawk]

oh now I remember that. Ok, I think we can just start by adding a version field to the backend and maybe push this info to locomotive. Then we'll see if we really need to tie some functionalities to it.

[guewen]

If this is about mappings, we could have something in the base mapper of shopinvader such as:

def finalize(self, map_record, values):
    mappers = self.many_components('import.mapper.version')
    for mapper in mappers:
        map_record = mapper.map_record(map_record.source)
        values.update(map_record.values(**self.options)
    return values

And in the mappers for a version:

 class MyVersionXYMapper(Component):
    _name = ...
    _inherit = ...
    _usage = 'import.mapper.version'
    _version = 'x.y'

    def _component_match(cls, work):
        return work.collection.version == 'x.y'

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.