Search Query integration for sub-datasets

[henri-egger]

The Problem:

There are some datasets of the tourism api, which do not have their own endpoint, but rather are a subset of another dataset.
Example:

graph TD;
    ODHActivityPoi-->Wineries;
    ODHActivityPoi-->Museums;

Loading

To get these subsets we have to provide additional search queries to the api.
Example for wineries: .../v1/ODHActivityPoi?type=32&subtype=2
However the current implementation of the databrowser does not provide inbuilt functionality for this.

First solution proposal:

• Probably the best solution would be to provide a new optional field in the DatasetRoute interface named "query" (by convention),
  which would later be processed and added to the url.
• This solution has the advantage of separating the base url and the search queries nicely
• Howerver, this change would also affect other parts of the databrowser, like the matching of the dataset configs (@gappc could you clarify this point further?).

[henri-egger]

@gappc Doing some tests i have achieved to add the query field and add the query parameters to the api, however adding a second config with the same pathParams overwrites the first one within the computeEmbeddedDatatsetConfigs function. This can be counteracted by adding the optional queries to the key of each dataset config. However then routing problems occur, as both configs have the same pathParams and we are directed to the first one of the two. How would you go about solving the routing part?

[gappc]

Hi @henri-egger if the query is added to the key, the keys should be different for datasets and sub-datasets. Of course the matching must then take into account the query part.

Possible example:

ODHActivityPoi -> key = ODHActivityPoi
ODHActivityPoi and query type=32&subtype=2 -> key = ODHActivityPoi?type=32&subtype=2

If think something like that should work. Note that the query part must be normalized (e.g. sort by name) before searching for a match in order to avoid problems due to different query sorting

Example:

"type=32&subtype=2" is the same as "subtype=2&type=32"

There is although a drawback to the whole solution: the query parameters are used by ODH as filters. Lets assume a user opens the Winery sub-dataset and changes the "type" and "subtype" filters (filters on the frontend are not implemented yet but will be done probably this year): in that case the user is not anymore in the Winery sub-dataset but somewhere else. I'm yet not sure how to handle that case. One solution would be to search for path/query matches on all URL changes. That way the user should see that the dataset / sub-dataset changed. I'm not 100% confident that the solution works, we need to try it out.

[henri-egger]

Hi @gappc, I created a new sub-datasets branch and implemented these first changes.
However i didn't understand where the routing is handled and couldn't implement a function which would take the queries into account also there.
Also, where would be the best place to use the apiQuery to set the queries?
Regarding the other problem, yes i think that would be a nice idea, however i think it should be comunicated to the user that he has swiched to another dataset by adding these filters.

[gappc]

HI @henri-egger, after a quick review I think your solution looks nice so far, good work.

The entry point for route handling is the routerWatcher. When a route changes, the resolve action in the datasetConfigStore.ts is dispatched. The resolution takes places from there on.

The embedded config matching is done in embedded.ts and should be improved to reuse the utils from config.ts.

Let me know if you have further questions

[gappc]

@henri-egger: after disussions on the topic today we came to the conclusion, that at the current project stage there is no need for dedicated sub-dataset support, sub-datasets will be implemented through filters only. Nevertheless, thank you for the interesting discussion, it shed some light on a topic that we had not on our radar.