Feature: Search agents by name, acronym and identifiers

[Bilelkihal]

Related issues:
agroportal/project-management#465
agroportal/project-management#571

Related UI PR:
ontoportal-lirmm/bioportal_web_ui#703

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.66%. Comparing base (85617ad) to head (e2ce607).
Report is 14 commits behind head on development.

Additional details and impacted files

@@               Coverage Diff               @@
##           development      #86      +/-   ##
===============================================
+ Coverage        71.26%   71.66%   +0.40%     
===============================================
  Files               67       67              
  Lines             3508     3653     +145     
===============================================
+ Hits              2500     2618     +118     
- Misses            1008     1035      +27     

Flag	Coverage Δ
unittests	71.66% <100.00%> (+0.40%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[syphax-bouazzouni]

you added query parameter to search by acronym, name and identifier; but they are already implemented in the line 9, with the function apply_filters or if not, need to put there.

[Bilelkihal]

you added query parameter to search by acronym, name and identifier; but they are already implemented in the line 9, with the function apply_filters or if not, need to put there.

Filters than in the line 9 are related to when we pass them like this:
agents?name=
agents?acronym=

in our case we are passing a search query that can be a name, acronym, orcid ..

and I didn't implement it inside apply_filters to not break other features that use the old approach

[syphax-bouazzouni]

you added query parameter to search by acronym, name and identifier; but they are already implemented in the line 9, with the function apply_filters or if not, need to put there.

Filters than in the line 9 are related to when we pass them like this: agents?name= agents?acronym=

in our case we are passing a search query that can be a name, acronym, orcid ..

and I didn't implement it inside apply_filters to not break other features that use the old approach

@Bilelkihal here, what is the difference between /agents?acronym=test&name=test&identifiers=test (the existent solution) and /agents?query=test (the proposed solution)

[Bilelkihal]

you added query parameter to search by acronym, name and identifier; but they are already implemented in the line 9, with the function apply_filters or if not, need to put there.

Filters than in the line 9 are related to when we pass them like this: agents?name= agents?acronym=
in our case we are passing a search query that can be a name, acronym, orcid ..
and I didn't implement it inside apply_filters to not break other features that use the old approach

@Bilelkihal here, what is the difference between /agents?acronym=test&name=test&identifiers=test (the existent solution) and /agents?query=test (the proposed solution)

The difference is in the UI,
In our UI we have an input for a query that can be (name, agent, ..) so in this case we have a query param that we need to deal with it without knowing the type of it.

The second case /agents?acronym=test&name=test&identifiers=test this works when we put an option in the UI to specify like search by: name, acronym or identifier with separate inputs for each of them which is not our case.

[syphax-bouazzouni]

The second case /agents?acronym=test&name=test&identifiers=test this works when we put an option in the UI to specify like search by: name, acronym or identifier with separate inputs for each of them which is not our case.

In the current UI we search by acronym and name using that existent interface, like this /agents?acronym=input_value&name=input_value ,in your case if you want to search in addition by identifier you do /agents?acronym=input_value&name=input_value&indentifiers=input_value

[Bilelkihal]

The second case /agents?acronym=test&name=test&identifiers=test this works when we put an option in the UI to specify like search by: name, acronym or identifier with separate inputs for each of them which is not our case.

In the current UI we search by acronym and name using that existent interface, like this /agents?acronym=input_value&name=input_value ,in your case if you want to search in addition by identifier you do /agents?acronym=input_value&name=input_value&indentifiers=input_value

No this will not work /agents?acronym=input_value&name=input_value&indentifiers=input_value

Let's say I seach for 1234123412341234

I'm passing this as a name too, and the intersection between agents with the name 123... and agents with identifier 123... will lead to an empty array always

[syphax-bouazzouni]

I'm passing this as a name too, and the intersection between agents with the name 123... and agents with identifier 123... will lead to an empty array always

it is not an intersection but a union, as done with the query parameter.

[Bilelkihal]

Finally I used the endpoint '/search/agents' which is indexed with a ranking and seach for all textual attributes of the agent

[jonquet]

Finally I used the endpoint '/search/agents' which is indexed with a ranking and seach for all textual attributes of the agent

Ok make sense, and stay consistent with what we have right now.
If we search in the back, we go to the Index with /search or a sub service of search
If we search in the front, we do this with all the data at hand.
No query="somehting" API at the level of our objects/models.