Project

General

Profile

Actions

Bug #1912

closed

API: search for typeID with subs logically connected with AND

Added by Andreas Olschnögger almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Category:
API
Target version:
Start date:
2022-12-13
Estimated time:
Found in version:

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]}]}


Related issues 1 (0 open1 closed)

Related to OpenAtlasDiscovery (origin) - Feature #1796: Improved searchClosedAndreas Olschnögger2022-08-29Actions
Actions #1

Updated by Alexander Watzinger almost 2 years ago

Actions #2

Updated by Alexander Watzinger almost 2 years ago

  • Status changed from New to Assigned
  • Assignee set to Bernhard Koschiček-Krombholz
Actions #3

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.

Actions #4

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.

Actions #5

Updated by Bernhard Koschiček-Krombholz almost 2 years ago

Ok. I'm still on holiday, but I will look into it tomorrow.

Actions #6

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.

Actions

Also available in: Atom PDF