That’s it. That’s the tip.
2 Likes
If anyone’s wondering how to go about it if you need to know if the value is empty or is it a no,
Create an option set with two values Yes and No
Use those values wherever you need to store yes/no in the database instead of default yes/no provided by bubble
1 Like
Lol, yeah now your yes/no’s cost 2-3 bit rather than 1
Indeed the labels of the option sets would be Yes and No, and the value attribute would be a boolean yes/no.
Oh yes
Idk if you should be living such a frugal life
1 Like
Add the field to data type
Create BE workflow to update it to yes
Run the workflow to waste tons of WU for nothing
or
Use negative field where no is true to mess up everything 
isActive=isDisabled
And if you want to use empty yes/no for search constraints just custom state list of yes/no’s ‘‘is in’’’ and add remove yes/no
The devil lives in the details… and charges by the bit
Btw this is one of the examples of Bubble understanding the user’s needs instead of blindly following the “correct” programming paradigm. If this wasn’t the case, any time you added a new yes/no, you’d have to do a bulk update to set the defaults to “no.” Or use a weird hacky “formatted as text” workaround. This lets you just say “is yes” under the assumption that the default is “no.”
1 Like
That is more of just an announcement of the fact, but should not be a tip to imply people should rely on that. Nobody should be doing this. Make your yes/no fields default to negative (ie: default to NO). For so many reasons.
Don’t. I tried that years ago, it is not optimal.
use of option sets does not cause issue in terms of amount of data loaded
I like that. That is a neat trick.
Sounds like you are afraid of the cost of WUs and are intentionally deciding to leave a field blank just for the purpose of not needing to pay WUs to update the field values properly.
The default of a Yes/No field should be No if it is expected to be the default. And if you need to add one to an existing data set and would need to run a bulk update to populate the field value you should, because it is not the best idea to leave a blank field that is supposed to be understood as ‘no’ when in fact it simply is not in ALL potential use cases of how to filter values between yes or no as demonstrated in my screen shots.
We WANT THIS EVALUATION BELOW:
NOT THIS
There’s nothing to “do.”
This doesn’t affect existing users.
Contrary to your belief that everything in life is about WUs, no. In this case I’m concerned about time. As is evidenced by my lack of giant essays.
There’s no “we” here. The existing behavior is ideal for my intended use case.
No one implied that it is.
Time to do a bulk update to keep data proper is less than 5 minutes. Nobody should leave a yes/no field empty for so many reasons.
Nah, there’s zero reasons to do it in my case. I only need to know if it hasn’t been set to yes. There’s a reason Bubble interprets it this way.
The reason is not what you believe. It was done that way because it’s broken, like a lot of other stuff. If it was done intentionally then, the evaluations I demonstrated that don’t work would ALSO still work.
But yeah, if you want to remain steadfast in your approach by all means do so. But I highly recommend other people not follow the same approach and to ensure there app data is correctly set and will therefore always evaluate properly.
Doubt it’s been broken for a decade. Seems like it would have been “fixed” by now if that was the case.
It’s not about an approach. You don’t seem to understand that in some cases, there is no practical difference between bulk updating and not, while in others, there is. I was the first to bring up bulk updating in this thread, because I’ve had to do it before.
My experience is that it depends on an app’s use for the data. If you explicitly need to define a new field’s default value as Yes then you definitely must run a batch to update existing values. Personally I don’t see the need for otherwise.
Bubble’s yes/no type returns a boolean (no) for blank values instead of a NULL. So I’m assured I can rely on just checking if the field’s value is YES.
These are things to take into consideration when updating tables in SQL for example where a blank boolean column can return False or NULL.
Unless Bubble decides to change the default behaviour of yes/no fields… 
1 Like
Exactly.
I find negative yes/no’s disgusting
The list of ‘known limitations’ or ‘known bugs’ is pretty long, and for things like this, it is not really something that needs to be fixed.
Okay, so you know it is not a hard thing to do. I would suppose that in a situation that most people would experience, that I think is the situation you encountered is that when you have a list of existing data and add a new data field to that custom data type which is a yes/no field, that you need to update the existing data with a bulk update.
Now, the choices would be
- to not bulk update any existing data and leave them all blank, and so therefore, as you’ve uncovered, will still “correctly” evaluate to ‘no’. And as existing users interact with their existing data in such a way that at some point they will set it to yes or no through some sort of action they take, which means you will likely get to a point where some have yes, some have no and some are still empty.
- Run one bulk update to in order to update all existing data with the correct yes or no value based on some value that exists that could be the determining factor of what that yes/no value might be.
AND if it is not either of those two choices, then there is just no point at all to add the yes/no field because if it is not either of those choices, you’d have no existing data entries with a yes value at some point.
What I would recommend for somebody is to use choice 2, running a single bulk update action if they have some determining factor that already exists to know if that yes/no should be yes or no, because you use that determining factor in the dynamic expression to evaluate as yes or no so it is a painless single bulk update to get all existing data with a yes or a no value and none are empty.
But, if there is no existing determining factor to know if existing data should be set to yes or no, then just use choice 1 because eventually over time as your users interact with the new data field all will become populated anyway and you do not have data entries with blank yes/no field values.
RANDO, Did you set any values to yes? If so how did you? If no, why not?
For some other reasons to not leave them blank for no, is that when you export your data as CSV or JSON the field value DOES NOT show as false, it shows as empty.
Remember, that False is not the same as Null and so an empty yes/no field is not the same as No.
@randomanon I’ve been building in Bubble for 7.5 years, 6.5 of them professionally. I’ve clocked in over 10,000 hours of development time. What that means is that I have made every mistake a bubble developer likely can make. My comments here aren’t meant to criticize, but to help you (and others) avoid the mistakes I’ve made and benefit from the hard‑won insights I’ve gained over the years.
The only time in apps that I opt to leave a yes/no field value empty instead of setting to no is when it is an attribute of an option set which has fewer options that should be set to yes than those that would need to be set to no, and since I can not export option sets, or run bulk updates, and manually going through setting each and every option is tedious, I will just let the ‘false identification’ of ‘is no’ on an empty value to be okay.
I hope you can take something positive away from this one and continue to grow as a Bubble developer.
1 Like