Closed hparfr closed 1 year ago
ping @sebastienbeau @simahawk @lmignon
@hparfr I agree, the approach is quite complex. Nevertheless, the initial motivation is to avoid extension by inheritance and replace it with extension by composition. This allows to avoid mixing apple and orange stuff into the same model. (Algolia is not ES).
@lmignon @sbidoul @simahawk We should talk about this during the code sprint
Note on V14: due to inherit mecanisme the server-env config is still broken see following PR: https://github.com/OCA/search-engine/pull/79
Let's do it !
Is anyone taking care of this already? Otherwise I could take it.
You can take it. Thanks @simahawk
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.
This have been done here : https://github.com/OCA/search-engine/commit/53b9096c8233f80d1aab4ceebc77f233af769015
Is your feature request related to a problem?
search engine object inheritence is too complex and not aligned with other practices we have in oca. It's the root of some bugs, provide a bad UX, and high barrier entry for new commers.
Describe the solution you'd like I suggest to remove
se_backend_spec_abstract
,se.backend.algolia
,se.backend.elastic
. Do a simplist implementation with prefixed fields onse.backend
Like:elastic_server_host
,algolia_app_id
...Describe alternatives you've considered
Alternative implementation can be found on oca/storage with sparse_fields.
Additional context
In all our (Akretion) implementations we do not have both modules installed on the same time. But even if it's the case (algolia and elastic installed altogether), having two or more columns on connector_search_engine views should not be something we should worried at. These kind of settings are not modified often.