Skip to content

Conversation

@sebastienbeau
Copy link
Member

@sebastienbeau sebastienbeau commented Jun 5, 2025

Right now each search engine implement its own test for testing the adapter.
As we start to have other contribution of search engine. A wrong test can make an adapter having a different behavior.
So at least each search engine adapter must match generic test.

For sure you can add additionnal test in your implementation to test specific case (error catching....)

3 commits, have been done.

    1. move the code without change (and without updating the cassette)
    1. adapting the test code and make the test more real (with cassette update).
    1. fix the implementation of each + add test and fix error in test

@lmignon @qgroulard

Note: on VCR we now match the raw_body so it avoid extra manual useless code that check that.

…ring

For now only move elastic test into a common class
The idea is to have the same test for all adapter
as all adapter should have the same behaviour
Now adapter have a generic testing flow
all adapter should behave exactly in a same way
additionnal test can be included to test specific case
like error catching
@sebastienbeau sebastienbeau force-pushed the 16.0-adapter-test-refactor branch from 89a3dac to 6ebf356 Compare June 5, 2025 13:59
@sebastienbeau sebastienbeau added this to the 16.0 milestone Jun 5, 2025
@sebastienbeau sebastienbeau changed the title 16.0 adapter test refactor [16.0] adapter test refactor + fix each method Jun 5, 2025
@sebastienbeau sebastienbeau force-pushed the 16.0-adapter-test-refactor branch from 55468ee to 044b4ce Compare June 6, 2025 14:38
@sebastienbeau
Copy link
Member Author

@paradoxxxzero can you check ?

@sebastienbeau sebastienbeau changed the title [16.0] adapter test refactor + fix each method [16.0] Adapter test refactor + fix each method Jun 6, 2025
@sebastienbeau sebastienbeau force-pushed the 16.0-adapter-test-refactor branch from 07e571c to 044b4ce Compare June 6, 2025 20:44
Copy link
Contributor

@lmignon lmignon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. A little comment...

binding = binding_model.browse(ext_id).exists()
if not binding:
item_ids.append(ext_id)
for index_record in adapter.each(fetch_fields=["id"]):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sebastienbeau If you modify the method signature, youmust modify the related ABC class https://github.com/OCA/search-engine/blob/16.0/connector_search_engine/tools/adapter.py#L41

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adapter = self.se_adapter
binding_model = self.env[index.model_id.model]
for index_record in adapter.each():
ext_id = adapter._get_odoo_id_from_index_data(index_record)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it's important to keep this method. We don't want to hardcode the field used to store the id into the index.

Copy link
Member Author

@sebastienbeau sebastienbeau Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My idea, but maybe it's not a good one, was to fix a wrong design that have introduced initially with the "_record_id_key" and that have been refactored

Some context:

  • Elastic or Typesense: the search engine use "id" as ID
  • Algolia it use "ObjectID"

Right now for Algolia (If we migrate with the current API)

adapter.index({'id': 1, "name": "Foo", "ObjectID": 1})
adapter.delete([1])
adapter.each() => [{"id": 1, "name": "Foo", "ObjectID": 1}]

So we need "outside" of the adapter

  • to inject the key ObjectID before doing the index
  • to call the method _get_odoo_id_from_index_data after reading data

With the change

I think it's better to move the logic of switching the right id inside the adapter and use the adapter like that

adapter.index({'id': 1, "name": "Foo"})
adapter.delete([1])
adapter.each() => [{"id": 1, "name": "Foo"}]

So the idea is to add a specific logic in the adapter for search engine that do not use "id" as keyword. So mostly it will need some adaptation in the Algolia connector

What do you think ?

@sebastienbeau sebastienbeau force-pushed the 16.0-adapter-test-refactor branch from 044b4ce to d01c447 Compare June 11, 2025 15:23
fix broken "def each" method for elastic
and implement addional test
make it work even with corrupted elastic index
@sebastienbeau sebastienbeau force-pushed the 16.0-adapter-test-refactor branch from d01c447 to e6cc527 Compare June 11, 2025 15:27
@sebastienbeau sebastienbeau force-pushed the 16.0-adapter-test-refactor branch from 36017d9 to bc1498e Compare August 31, 2025 15:11
@sebastienbeau
Copy link
Member Author

@lmignon Now it's ready ! can you update your review ?

@lmignon
Copy link
Contributor

lmignon commented Sep 1, 2025

/ocabot merge major

@OCA-git-bot
Copy link
Contributor

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 16.0-ocabot-merge-pr-211-by-lmignon-bump-major, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit 0fc7ed0 into OCA:16.0 Sep 1, 2025
7 checks passed
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at 9962bdc. Thanks a lot for contributing to OCA. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants