I have a data type userList which contains three fields.
My question is about the best way to set up my data structure wrt WU. I need to access these fields nearly constantly, so instead of always searching for the data, I made it a related field on my current user.
current user [data type]
userLists [field] [a list of userLists]
current user's related userList's field1 [how I currently access the data]
I was working under the assumption that by accessing the userList data in this way, the data was already in memory since page load (or logging in?) and would not trigger searches. But while examining my Logs, I can see that there are a lot of searches and WU’s resulting from accessing my current user's related userList's ...
Am I wrong about the data already being in memory? Would I instead make the fields directly in the current user? (It does not give me quite as much flexibility to group sub fields this way though…)
What is suggested? The app is like a task manager, so sometime these data lists could grow in size, but let’s say it might max out at around 200 records/list typically. There will be many lists, 20 or more.
I’m happy to hear all suggestions. My #1 question is about whether my data is already in memory because I think I may have misunderstood something. But I’d also like suggestions on how to best set this up to minimize WU because the app will become impractical very quickly it that is not kept as low as possible.
Under the hood your list of userLists is just a list of unique ids (list of texts)
So on page load you are only loading that lists of texts. The Things themselves are not cached. It is as soon as you need information from a field of those userLists that Bubble will need to go a layer deeper and turn that unique id into a Bubble Thing/object.
I do not know if Bubble needs to convert all of the unique ids in your list into Things at that point, or if it can just convert the one you need. Not sure on which one it would do.
You are seeing searches in your logs just from referencing a list though? That doesn’t sound right.
That makes sense. Thank you for clarifying. Also, thanks for the link to that thread. Interesting.
So what then is a good strategy to load my entire object into memory instead of just a reference to it?
I’m also using a series of repeating groups in a hidden popup that do a search on page load. After that I am getting the list of things from the RG instead of doing a search. But it still seems like accessing these is triggering a search (I am trying to avoid that).
With few exceptions, I am trying to run my app as much as possible from the front end which is what I’d like to do regardless of WU. So how can I get an list of records of a data type into memory so that using all the fields does not use any search or WU?
(BTW-I subscribed to my account about one week before switching to WU, so I am not currently being charged by WU. It’s giving me a great opportunity to see problem areas without a real $$ expense to learn my lesson!)
TBH I would more focus on building, whether you load the objects first, or load them later I feel like it would have the same impact. It really shouldn’t be triggering searches though except for the first time the RG’s list is retrieved.
But the quickest way to get everything loaded on the client would be have RGs with all the searches you want, then have everything point to the RG’s list of things. That will be the absolute minimum amount of searches.
Yea being on capacity plan still lets you do some experimenting and database restructuring without having to worry about the cost right now
