Another feature would be to programmatically upload them with their secondary attributes as well. I need to label a list of thousands of static options with multiple attributes and doing this manually is unfeasible.
@eve Is there any plan to update the option set management system? It’s been radio silence for nearly 2 years so it seems like it would be best to restructure the data structures to utilize database datafields rather than option sets at this point.
+1 for new feature of being able to sort a Repeating Group by an Option Set. Currently, I have a field called Status which is an option set and that field doesn’t show in the list of fields you can sort the RG by. 
FYI: @arturio put together an interesting Option Sets Chrome extension: [New Extension] Bulk import from CSV file for Option Set
I haven’t seen this mentioned so I wanted to notify everyone:
An Option set’s display text (the built in attribute) will keep the original name for search results. Even after you change it.
Example: I have an Option set for Colors. If I change “Red” to “Rojo” bubble will retain the original name of “Red” for search results. “Rojo” will never appear in results - even after the change.
I have a data type of Cars and a field for Colors which is a type: Option Set. And I selected the “Colors” option set.
If I use an input to run a search on a repeating group, where the search is performed as “any field contains” bubble will always search for the original name of that option - not the new one.
Here you can see if my users search for “Red” all of the things with a “Rojo” color show up in results.
And then if my users search for “Rojo” nothing appears in the results.
Here’s a public editor. Feel free to add a new color to the option set, change the name of that color, and see for yourself.
A bug report was submitted with this editor. Bubble confirmed the behavior. I’ll update this thread if bubble pushes out a fix.
I’m not sure what my plan is for now. I guess it’s to create another field that just mirrors the option sets name. This way if I change the name of the option set, the mirrored text field will help my users find the correct results.
Thought it was worth mentioning to the group. Hopefully this saves you time.
(sorry if this was mentioned before)
Make a RG that has a Data Type of Status and Data Source Get All Options. Then for each cell of that repeating group put another repeating group that does a search for User (or whatever) whose status is current cell’s Status.
Is this still the case in 2022, no limit on the number of options?
Also, Is there a limit on the number of attributes per option?
Thank you,
Woah, I know this is an old thread but even today uploading thousands of static options would impact page load times as all of those would get loaded on every page (in your case usually unnecessarily if I had to guess). What use cases require thousands of options that couldn’t be better implemented using Bubble things?
I know this is an old thread, but I had a question.
I understand that the point of Option Sets is that they are static, but I’m wondering if there are any tricks to dynamically changing their attributes.
Let’s say I have an Option Set called “API integrations”. This will be a list of software. Each software will have a text attribute called “Instructions”.
Let’s say I want my users to be able to dynamically enter text for each software’s “instruction”. Is there a trick to make this happen in this scenario?
Thank you
Did you manage to resolve this issue with a workaround? I’m hesitating about adding Option Sets in my use case because it is probable that something may need to change.
Is it possible to create an ‘Alias’ as an attribute and use both the original name and the Alias as the search? Then use a conditional to display the Alias as the new name when alias is not empty?
I did try on your editor but the search behaviour still has the same issue.
I’m new to bubble so I don’t want to go down a rabbit hole here if there isn’t a solution.
think it will always retain the original name of the option. If you think it will ever change, you should create a DB item instead.
Hi! Haven’t been here a while. The idea was to leverage the speed of options for large lists of simple text. Loading a text file with thousands of lines is not going to have any impact, while loading thousands of items from the database would. I agree that for more complex option sets, especially those with images, the impact be horrible at a large scale.
Large lists, whether loading from the db or from option sets, will slow page load time. The issue with doing it in the form of options sets is it would be loaded on every page regardless of whether those thousands of items are needed on said page. Then there’s the headache of administration/upkeep of those thousands of options… so better approach is to save this in a 3rd party database like Algolia or Typesense and fetch what’s needed as needed. These services are tuned for quick response, so speed isn’t an issue
Are all option sets loaded or only those which have been referenced on the page being loaded?
Option sets are static JSON definitions and all are available in any page. I think they’re defined in static.js. (Long way of saying the entirety of all option sets is “downloaded to” every page. Though note that they aren’t “reloaded” or anything on a page change. They are essentially cached upon the first page hit in the same way that all plugin code in a project is downloaded upon the first app hit and then need not be fetched again.)
