Limitations of Using the "Created by = Current User" Constraint in a "Search for"?

Hey everyone - I have a general question on how to optimize performance for loading & sorting data in a repeating group.

In my app users upload Audio files. I have a page with a repeating group to display the metadata for the files a user has uploaded. The Current User can only see the files that they have uploaded, nothing else.

I achieve this by the standard “Search for” with a constraint “Created by = Current user”
example1

For sorting data I add a Conditional to the Repeating Group to change the Data source. Again I end up applying a constraint of “Created By = Current User”.

example2

My question is at what point does such an implementation lead to performance issues? For example if I had 1k users with 1k audio files created by each user, would this slow down the load time of the repeating group data? Is there a better way to achieve this?

You could add a field to the user which would be a list of audio files and make it a related field to the data type of audio file you set up in your app (Music Item)

Then instead of doing a search for music item with a constraint you can use : current user music items

This will get the list of music items on the current user and would avoid needing to fetch all Music Items and filtering them all

Why are you changing the data source for sorting the data or am I missing something? The repeating group holds all the “Music items” and you’ll be sorting through those music items through a variety of sorts and filters, but ultimately your source would always be those music items? Thus your RG should be “search for music items” and you’d use the filtered constraint to filter depending on the dropdown options (or toggles, buttons etc).

I did what you’re trying to do for books and had advanced filtering like Amazon without a single condition on the RG and all under one “Search” just through the constraints, I think I use filtered constraint a few times.

Thanks @boston85719 for the feedback. I was reading through the Bubble Manual on this topic. What are your thoughts on Option 3 given my situation?

@tzuork I was following the direction as shown in this Bubble tutorial video

Ah I see, I’d also like to know which way is better.

I think there are more limitations with conditional formatting than my way; filtering. When I was looking into it before I must’ve come to the conclusion that conditional formatting was limited somehow in comparison.

When I was doing advanced filtering, experts on here told me not to use conditional formatting.

Be nice if any experts could chip in.

Reading this thread (point #3):

It seems that I’m on the right track with my current implementation? Where each of my Music items have one single User, and thus I continue to do the server side Search for all Music items where Current User is the Creator?

You could implement some test data and do a test to see which returns better results.

I did this for analytics when I wasn’t sure if doing a list of analytics on a particular listing was better than having a separate database data type for analytics and just put the ID as a text field of the listing…as a side note, the description from this linked post indicates that when you use a data type of thing B as a related field on thing A and you search for thing A you are loading only the ID of the related thing B in text form, and not all of the related data, so my use of adding a text field on thing A that is the ID of thing B makes no material difference to the search results performance, but it does hinder my ability to make quick references to the related thing B.

What I found was a list of things took longer to return the results than having a separate database data type and do the search on that data type because of the large number of items that would have been on the list.

I believe what you linked to, written by one of the founders, could be considered as the expert advice best to adhere to.

So, if your list will go beyond 100 items, you are probably on the right track with your setup…there has been some recent activity on the forum regarding the use of multiple relationships, so that you have thing A as a related field on thing B and have thing B as a related field on thing A…one user reported this as their preferred method for optimal performance and mentioned a course they were planning to release with demonstrations but I have not seen the course released yet.

There was also a book released

that may be worth purchasing to read through to conjure up some other ideas of how to optimize

Excellent - thanks for the feedback @boston85719!

My conclusion from reading other posts and the Bubble Manual is that I should keep the searching on the server (using the “Search for” vs a list). I’m going to explore the idea of making a “MusicUser” type of lookup table.

1 Like