I am a bit flabbergasted at the data search function on Bubble
We have a relatively small dataset of 100 records displayed in a RG. We have a search bar at the top and we want to refresh the RG to show the records matching the search keywords.
Some keywords to search as text or numbers in the RG item, some are other related database items. For example, in our case we are talking about payments, so we can search by payment reference, but also by paymentâs accountâs userâs firstname etc.
First we did a search directly into the DB.
Second we did a single search in the DB with an invisible âdataâ RG containing all the data and then we applied filters on that data locally and display the results on the visible RG.
In both cases:
The search is super slow. For 100 records on stage it takes a minute to search. I cannot imagine the time it will take to search 100,000 recordsâŚ
The visual transition on the RG is non-existent. The RG doesnât move, there is no loader, then suddenly the new data shows. There is no visual cue for the end user to know the system is searching for data. I tried to play with hiding and showing the RG but that does seem to create more complications.
So whatâs happening here? Do I really need to create a searchable string per database item? The data redundancy will be unmanageable. We live in a country where people change names at a whim, so this means that each time someone changes name I need to re-index all database items related to this user? Please tell me this is not the way to go?
I canât say for sure since I havenât seen how you structured your search but 100 records shouldnât take a minute to search - assuming your search is fairly simple without complex advanced filters.
If the fields that you want to search for are just in a single data type, you can just search for that data type in the rg instead of using actions to display it.
You can then add constraints to the RG search and reference it to the inputs while adding an ignore empty constraints
RGs have a built in loader but we can all agree it doesnât look nice.
If you want to create your own loader, youâd need to do some hacky set simple ways to go about it. You would also need to set up the logic as to when it should be shown and hidden.
Do a search for payment: merged with : do a search for payment: merged with: do a search for payments: etc. etc. (now 5 merged searches).
Use the Data RG and filter:advanced:this paymentâs reference number contains search inputâs value or this paymentâs etc. etc.
Option 2 is definitely much slower than Option 1. Itâs somehow counter intuitive. I thought that since we donât need to search the database and the data is already on the hidden RG, the filtering should take much less time than doing 5 queries and merging them?
I do not understand this sentence. Could you please elaborate or illustrate with a screenshot? Thanks.
accountâs userâs first name matches the search OR
accountâs userâs last name matches the search
I could not do a single search for this could I?
Isnât this what I did in the option 1 I described? If not, how do you otherwise search data directly in the RG? Arenât contraints in the do a search function AND (and not OR) constraints?
You can do all those searches in a single advanced filter instead of all the merges, but I donât dare to use advanced filters too often. My approach is to have a different search for each field in the conditional tab.
So I would create an option set âsearch typeâ, with reference number, receipt number, accounts code, etc.
Then add a dropdown next to the searchbox that allows users to change what field theyâre trying to search. Set conditionals on the repeating group that will have a different data source for each search type.
Another approach would be to have a naming convention for all the data in those fields. So letâs say âreference numberâ is usually written as ref_55602 and âreceipt numberâ is written as rcpt_55602. You can set conditionals that will change the field it searches based on those beginning keywords. Although, it may not be user friendly, as users probably wouldnât remember those keywords
Right. The search bar here is meant to be a quick search, we also have advanced filters. But the way the search bar needs to search is by those criteria with an OR logic.