That’s it. That’s the tip.
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
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
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.”
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…
Exactly.
I find negative yes/no’s disgusting