would there be a way to prioritize data when doing a search for something?
Example
- A user wants to add a baseball card with the name “Boris the Batter”
- A workflow is run looking for “Boris the batter” in a data set “Baseball Players” that contains 150 entries.
The vast majority of users will add the same 10 players. Would there be a way to say “hey, first look at these 10 entries, and if a match is not found, go look down the list”. Instead of randomly/ alphabetically - whatever bubble does - downloading chunks of data and search for a match.
Can you have another data type that’s the popular players? So it searches that list first, and then the User can specify if they want to search the whole list instead?
Tal
nocodify.com
Perhaps you could have a yes/no field for “popular player” and search for yes only first? Not sure if that would be faster. I think @Nocodify’s solution would probably be faster, but it adds potentially other problems by having two datatypes.
I did toy with a tag and/or a different data type. Both are good ideas but with some shortcomings.
Having a separate data type does come with some complications from having to deal with several data types for the same type of data. But the main drawback is that it would involve a user action, and that in itself would somewhat defeat the purpose of speed improvements.
- User searches in “Harry the Hitter” and nothing is found
- Presented with prompt “we couldn’t find anything, expand your search”
- Searches again from the extended data set and finds Harry the Hitter.
On a 8sec workflow run to search and set up profile, the actual time would easily be tripled with the additional steps. And for this specific user case, the search and saving the searched data into a new dataset is all happening in the workflow, it wouldn’t really work anyway. And it would also provide for a less than optimal user experience.
For the tag idea, I never set it up to run tests, because it would be a fair amount of work. And my thinking was that adding more search constraints would end up slowing it down in the end. But I might be wrong here, I don’t really know how the constraint hierarchy works?
But having slept on it. In this use case (it’s not actually baseball players, since that obviously wouldn’t need to be saved over to a separate data set) the search on the front end is actually really fast. Where it becomes slow is on the back end when searching for more data tied to “harry the hitter” and saving it into a new Thing.
I.e.
Search for Boris the Batter - press “create profile” and a workflow runs to create a new thing “Profile” and in that workflow multiple searches are run doing a search for Boris the batter’s, height, eye colour etc.
I suppose what would really speed it up is to somehow preload that information before user clicks “create profile”. I suppose that could perhaps be stored as temporary states and then grabbed from there when the workflow to create the new Thing is run. But this could potentially create issues with the states not having been populated completely before the user clicks “create profile” I suppose.
Edit. Sorry this reply ended up with me just thinking out loud haha.
