Bug #1912
closedAPI: search for typeID with subs logically connected with AND
Description
If I want to filter by types I use the search parameter (https://redmine.craws.net/projects/uni/wiki/API_03#Search).
Consider following search parameter
&search={"typeIDWithSubs":[{"operator": "equal", "logicalOperator": "and", "values":[A,X]}]}
and a type hierarchy like this:
A > B > C X > Y
I would expect te result to have those elements that have type A (or any subtype) and type B (or any subtype).
This does not seem to work. For example, in the concrete example of the Shahi instance, I want to search for an artifact that is made of the material Clay (142) and Paint (143).
So the search parameter would be
&search={"typeIDWithSubs":[{"operator":"equal","logicalOperator":"and","values":[142,143]}]}
However, this search returns no result. Although there are artifacts with these properties (https://shahi.openatlas.eu/entity/5178).
If you use "typeID" instead of "typeIDWithSubs", the search works in this specific example because no subtypes are involved.
However, I need the search with subtypes.
I could imagine that currently it is handled that the entity needs to have (A and B and C) and (X and Y) while it should be (A or B or C) and (X or Y), when looking at the first example.
Request with sub:
https://shahi.openatlas.eu/api/0.3/query/?view_classes=place&view_classes=artifact&limit=10&search={"typeIDWithSubs":[{"operator":"equal","logicalOperator":"and","values":[142,143]}]}
Request without subs:
https://shahi.openatlas.eu/api/0.3/query/?view_classes=place&view_classes=artifact&limit=10&search={"typeID":[{"operator":"equal","logicalOperator":"and","values":[142,143]}]}
Updated by Alexander Watzinger almost 2 years ago
- Related to Feature #1796: Improved search added
Updated by Alexander Watzinger almost 2 years ago
- Status changed from New to Assigned
- Assignee set to Bernhard Koschiček-Krombholz
Updated by Alexander Watzinger almost 2 years ago
- Target version changed from 7.9.0 to 7.10.0
Moving to next version before release because of missing feedback in last 2 weeks.
Updated by Alexander Watzinger almost 2 years ago
I just remembered that this is actually kind of urgent because it blocks finishing the last issue for the SHAHI frontend. So in case you fix it after the New Year release please do it in an extra branch from main and I will than consider making a minor release for this.
Updated by Bernhard Koschiček-Krombholz almost 2 years ago
Ok. I'm still on holiday, but I will look into it tomorrow.
Updated by Bernhard Koschiček-Krombholz almost 2 years ago
- Status changed from Assigned to Closed
- Target version changed from 7.10.0 to 7.9.0
I could imagine that currently it is handled that the entity needs to have (A and B and C) and (X and Y) while it should be (A or B or C) and (X or Y), when looking at the first example.
Andreas, you are correct with this statement. For reasons of simplicity, I just put every ID in a list to check if the entity has all (and) or any (or) of these IDs as Types.
Now each Type ID get an own list of itself and all Subtypes.
Changes are in develop.