Revisit search history

[BeritJanssen]

The current behaviour of the app is to save each query in the database. As of #243 , this might become messy: every filter modification leads to a new search, which means that many, many queries will be saved, while the user may only be interested in keeping specific ones.

Might replace this behaviour with giving the user the option to bookmark (⭐️) a query. This then also serves as a list from which to download (#188 ) results later on.

[jgonggrijp]

I'm in favor of bookmarking 👍.

As for downloading from the bookmarks list, I'm in favor of that too, on the condition that you can toggle individually which bookmarks you want to download. I guess this is what you meant.

[BeritJanssen]

Exactly, there should be a way to check the requested downloads. The revisited version should also use p-table for consistency with other tables.

[jgonggrijp]

One more thing: for debugging purposes, we may also want to save non-bookmarked queries for a limited amount of time. We can hide those from the user.

[BeritJanssen]

@alexhebing warned me of the sqlite feature to lock databases while they are being written too, and thought this might cause problems with 30+ users. So just to be sure, I disabled saving of queries temporarily (553cdf8).

[BeritJanssen]

Hmmm... Getting second thoughts on this. Problems with the bookmarking approach:

• user cannot download a set they are interested in right away
• in the search history, as all corpora are being shown, selecting the fields to download might become very complex: for which corpus are the settings done? Show selection only when a corpus is selected?

Drawback with keeping as is is obviously that a lot of queries are being saved in the search history, possibly also irrelevant ones. But we don't know yet whether this is a performance bottleneck.

[jgonggrijp]

Hmmm... Getting second thoughts on this. Problems with the bookmarking approach:

• user cannot download a set they are interested in right away

Unless we make an extra button for that, of course.

• in the search history, as all corpora are being shown, selecting the fields to download might become very complex: for which corpus are the settings done? Show selection only when a corpus is selected?

I suggest: first let the user pick a corpus and then only show the bookmarks for that corpus.

Drawback with keeping as is is obviously that a lot of queries are being saved in the search history, possibly also irrelevant ones. But we don't know yet whether this is a performance bottleneck.

Modern RDBMSs have no issue at all with managing millions or even billions of records in a single table. They use B-trees specifically for this purpose. If it ever becomes a bottleneck, we will notice it, and we will also be able to quickly solve it by adding a permanent index.

(I'm still in favor of doing both: let the user create bookmarks, but give admins access to all queries ever. If we're really worried about storage, we can periodically prune all non-bookmarked queries that are older than, say, a year.)