I am a bit flabbergasted at the data search function on Bubble :astonished:

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.



1 Like

I tried both:

  1. 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).
  2. 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.

That explains it :sweat_smile:

Based on what you said, your search sounds fairly simple. You don’t need to do these things

What’s the thought process behind merging different sources?

Are you searching for the same data type but with different constraints, and then merging them in one list?

Just do the search for that data type directly in the RG and add constraints.

The constraint/s would then reference to the input’s value

Ignoring empty constraints, well, basically ignores the constraint if the input’s value is empty.

Adding something in the input would dynamically update your search results



1 Like

I need to search for payments whose:

  • refrence number matches the search OR
  • receipt number matches the search OR
  • account’s code matches the search OR
  • 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?



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *