Hello, I am a software engineer.
Just thinking about the future of my application.
If I create a new field and tick “This field is a list (Multiple entries)” how does this work?
What is the time complexity of storing it as an array (as I assume it is).
Why don’t people just use UID’s and link to another db?
How many entries can I have in the list before it becomes slow?
I dont want to use lists if it will become very slow in time.
You’re asking how long will it take to store that list?
From my understanding Bubble is essentially already doing this under the hood. The reason we don’t do it is we can just make the expression This Car's Manufacturer's Office's Phone number instead of doing a ton of nested database searches to end up at the same place. And it is better performance letting Bubble handle the relationship
Like thousands (is it essentially storing a list of UIDs so it is just text) but still it is not a good idea to have long lists tied to your datatype for many reasons.
If storing thing in a list becomes slow.
How do you solve this simple problem:
Likes on a post.
You have a Data Type Post
With the field Likes that is a List of Users
Is a post gets 100,000 likes the list would be 100,000 long. Is there a better way to do that?
(This question does not relate to me, I am just learning about bubble before I seriously make something)
Yes, you make another datatype called “Like”
With a field for Post (Post datatype) and a field for User (User datatype)
When they click like it creates a new Like, sets those two fields. Then later in the future if you want to look at all your liked posts you do Do a search for Like, constraint User = Current user, then do :each item's Post
Or to get all the Users that liked a specific post, you do Do a search for Like, constraint Post = [specific post], then do :each item's User
There would be some more logic to check first if a Like exists already but you get the idea 
Do a search is a serverside database query, where it can narrow down the results with some constraints and deliver a list to the client, and it could be a partial list so as they scroll it can deliver more and more results.
When storing a list, in order to narrow down certain things you want you have to do the :filtered operator after it, but that is a client side filter so it locks the whole browser (if the list is long or the Things are “heavy” with lots of field) while it downloads and displays all results (could be thousands if they are posts!)
The :filtered operator is more capable, but you can always have a database search with some constraints then do :filtered afterwards. You’ll notice search constraints are pretty basic but get the job done most of the time.
EDIT: retyped because I am bad at explaining
This was a fantastic and simple way of writing out something I’ve been pondering for a while, so thanks for pointing me in the right direction! I want my users to be able to ‘like’ recipes’, so I created a new data type called “Like”, with 3 fields: ‘Recipe’, ‘User’, and ‘Yes/No’
When they click the ‘heart’ button to Like a recipe, I do a search for 'Recipe = Current Page Recipe", "User = “Current User”. If Count = 0, it creates a new Like, with Yes being set as ‘Yes’. If Recipe & User already exist, and Yes = Yes, it changes Yes to No, and if Recipe and user already exist, and Yes = No, it changes No to Yes. In this way only the first time the ‘Like’ button is clicked, a record is created. After that point every time it is clicked, it simply toggles the ‘Yes/No’ field.
Here is my follow up - I am using the outline heart icon to indicate ‘Not Liked’ and then I use the solid heart to indicate ‘Liked’. I’m using conditional on the icon itself to switch this icon from outline to solid, and to do so it is Doing a search for: “Recipe = Current page recipe” and “User = Current user”. Is this the most efficient way to display the heart Like status? I wonder if it’s taxing on the database (WU consumption), and I notice a slight lag from clicking the heart to it switching from solid to outlined & vice-verses (‘slight lag’ being more like 250ms).
Thanks!
Yea not sure how else to find if the Post was liked without checking the database. Maybe something could be done to “save recent liked posts” under the User but that would only save some WUs on recently-looked-at Posts.
Make a yes/no custom state inside the cell, then add the set state action in each existing workflow, then add another condition on the heart icon to also have the heart when the custom state is “Yes”. Then when they click it will set the custom state right away and visually change while it is making the database change.
That’s a great idea to get immediate feedback on the ‘Like’ heart icon.
Yeah I couldn’t think of another way outside of ‘Do a search for’, outside of going more rudimentary and instead of creating a new thing ‘Like’ and searching the Likes table, instead having a cell on User called ‘LikedRecipes’ with just a list of recipes they like. The downside to this approach, which is why I call it rudimentary, is it involves a list that gets longer and longer; there’s nothing stopping a user from liking 1000 or even 10000 recipes if they want to; I’ll stick with the current setup for now as mentioned above, and see how this impacts WU use and will report back later - thanks for the tips, and thinking out loud with me!
Yea no bueno on the giant list, regardless of it being directly on the User or on a satellite datatype.
Bubble is pretty smart with caching things so when you do that initial search in the conditional on the heart icon, that search result should be ready already for the workflows to know if it is a yes/no.
Here’s an interesting way I found that while it didn’t speed up the Yes/No display, it would make it easier for me to re-use these hearts on pages - I created a small group with type ‘Like’, and in the Like the Data source is 'search for Likes: Recipe = Current recipe, User = Current user" and then on the icon I just referenced whether parent group Like’s Yes was yes or no. This would make it easier to also include any other messaging or differentiation between the ‘Yes/No’ without going into all of the Do A Search Fors on each individual element.
