I know the “Search for” function in Bubble is querying the database.
Problem is, I have files scattered across data types (but always bound to the same thing as part of the privacy rules). Now i’m looking for something to create sort of an Admin overview of all the files that I have in an app.
Is there a straight to the problem fix for this sort of thing?
I know i can setup a seperate table where i add all document etc. but from a removal perspective connecting this single table to all other tables is burdensome.
Unfortunately having a singular File datatype (with a Bubble file field) would be what you need.
As of now you would need to either create tons of RGs, each for each of your datatypes.
Or one RG with the type “file” and just merge tons of searches together for each file field. But you will lose all references to their parent’s thing going that route.
Indeed way too much work. We have way to many tables.
Kind of figured the best way to go about this is setup a seperate S3 as the purpose for this is Admin file oversight (in app). Clients would like to retrieve files from the app so instead of building nightmare tables we may as well give them the keys to their own bucket
Yea I use Wasabi S3 storage and keep a File datatype that contains the key, bucket name, bucket region, filename, filesize, etc. Easier to manage too you can filter files by the creator, see who has the most storage used
How you handle references back to the parent Thing is up to you. If you just care about the actual files that is easy, one big RG.
If you want to be able to go back to every file’s Parent thing you may need to do something along the lines of an Option Set on the File, telling you which datatype the parent thing is, and a text field for the UUID
Everything above can pretty much be done with Bubble storage as well
How I typically manage these things is indeed having an option for the table in combination with the UID for the individual record. Unfortunately Bubble does not allow the Search expression to be triggered by a variable like the option so quite a bit of work to get all options setup but that’s a different challenge.
Our clients prefer AWS (even though Wasabi is an AWS overlay i believe) but since it is just a bunch of docs security is more important than performance. Costs are irrelavant. We used Wasabi to see how we could get files into openAI (which was a complete nightmare due to openAIs filetype scanning based on name (before MEME) - anyhow we sorted it out and no longer required wasabi but still have a S3 i believe..
We have a multitennant setup so indeed capturing bucket and keys in database at topaccount level and performing backend handling (one way storage) will do. No need to lookup whatever is in the bucket. It is purely hypothetical contingency measure.
