I’m currently working on creating a demo application for a company, focusing on researching sales representatives and viewing their reviews. The requirement is that any admin should be able to modify the database structure, adding new fields and entries. Is there a way to achieve this in Bubble through a workflow? Or perhaps, do you have any other suggestions for a solution?
Bubble’s database schema cannot be modified during runmode. It can only be modified through the Bubble editor.
I guarantee that this is a good thing, as giving Database Schema modification rights to people can lead to all sorts of nasty things.
There are definitely ways to organise your Database that will mimic what you are trying to achieve. Don’t let admins create new tables; let them create new rows on a table which acts like a table of tables. (eh, not the best way of describing it, and the specific implementation depends on your usecase)
What exactly are your admins going to be doing? What ‘tables’ and fields will they be adding?
Thank you for the suggestion; I will try that out. Regarding the question “What exactly will your administrators be doing? What ‘tables’ and fields will they be adding?” – the core of the application is a vendor database with extensive details for each vendor, which should be expandable by adding new columns with alphanumeric fields. Admins should also be able to create new filters. I believe this might be equally challenging in run mode, wouldn’t it?
believe this might be equally challenging in run mode, wouldn’t it?
Not at all Not because achieving this is super simple, but because achieving runtime database schema changes sounds like a nightmare (definitely not possible on Bubble)
To allow venues to add custom alphanumeric fields to their vendor page.
This is simple. Create a dataType called Feature. This contains all the information about the basicvendor’s custom feature. (Correct me if i’m wrong, I imagine that these features will not be filterable and will just be displayed on the vendor page.)
Text Value (text) alphanumeric, can be either text or number. But will always be a string.
Type (text OR optionset)
I’ve found this useful in the past because it allows you to create different feature types which are displayed differently across your app. Instead of putting all the custom features into a repeating group and formatting them the same, you’ll be able to differentiate the features and put them in different spots of your app.
You can then attach a list of Features on the Vendor dataType and load them into your repeating groups using Vendor’s features’s filtered (Constraint: Type = 1 or 2 or 3…).
If you think your vendors will add hundreds of features, then maybe it would be best to run a search instead of attaching a list to the Vendor dataType.
Other information about the vendor’s feature would be added as extra dataFields.
Admins should also be able to create new filters.
This one is slightly more complicated, but nothing ridiculous.
Filtering is a big factor of optimal database design.
Do you want to filter vendor products using custom vendor filters? Or are you filtering Vendors?
What types of filters will vendors be adding? Give us a few examples.