Feature/vulcan search #7
Conversation
There was a problem hiding this comment.
In terms of code, this is ready to merge, good job. In terms of functionality, I am a little concerned about how opaque the navigation within search results functions... Firstly, it is currently impossible to see how many 'layers' deep you are within a search, which opens the door to potentiallly missed results for the researcher. Moreover, I think it is not logical behavior that when you are in a search result and change the original search filter, it does not change the underlying filter, but instead creates a new filter on top of the existing one. And this while there is already functionality to add several filters. However, there are various ways of implementing this, so let's discuss next week!
|
The last commit gets rid of the confusing layering structure whereby search are based off one another. Now, every new search is based on the 'standard Layout', and we don't store the IDs of other 'base' Layouts anymore. |
|
Great suggestion to modify the search function! This makes using the search interface a lot more intuitive! <3 |
Close #6
Close #8
This PR fixes the search functionality in Vulcan and adds utilities to handle timestamps.
This relies on the
feature/vulcan-searchbranch of the main ParsePort repo.The Vulcan frontend features quite an involved menu structure that lets the user construct SearchFilters, which can be used to filter certain results (e.g. only show sentences that involve the word 'cat').
Whenever the Websocket server receives the
perform_searchsignal, it retrieves the Layout the user is currently looking at, takes the SearchFilters that are sent along with the signal and applies them to the Layout, creating a new Layout representing the search result. This new Layout is stored in the database under a new unique identifier and a reference to its 'base' Layout. The identifier is sent to the client, triggering a redirect to the new Layout with the search results. If the user hits Clear Search, the old 'base' Layout is returned. Having unique identifiers for search results means that researchers can send search results to their peers simply by sharing the URL.To avoid that the DB gets cluttered over time with old, unused Layouts, I've added a script
remove_old_layouts.py. The idea is that this script is run once a day (or less often) to clean up old Layouts that haven't been used for 90 days. Of course, we can increase the expiry date to 365 days or to whatever the researcher would like.Still to be done: if you open the URL of a Layout that represents a search result, you see the filtered corpus, but the search menu remains empty, so you cannot see the parameters used to perform the search. I've set up a meeting with the original author of Vulcan to discuss this.Edit: the developer of Vulcan and I discussed this, and it was easier than I feared! Search params are now restored :)