I have to be missing something obvious, because it’s wild to me that this would not be a feature. I have two fields in a table, let’s call them “yes/no 1” and “yes/no 2”. I’m doing a search later against records in this table, “Do a Search For”.
In constraints, I’d like the constraint to be that “yes/no 1” = “yes/no 2”. Left side, no problem! I can pick “yes/no 1”. My options next, also no problem. I can select = among <>, isn’t in, and is in etc. But on the right side, none of the other fields for this data are listed. I can’t select “yes/no 2”.
Already I’ve spent an entire morning working around the limitations of the query logic builder just to get to the point where I have these two fields to test against. Is there actually no way to perform this as a constraint in a search? Some of the limitations I sort of get - but this one is bewildering.
Hi there, @timothy.alvis… as I mentioned in a similar thread, I believe you would need to use an advanced filter. If you don’t want to go that route, I guess you could consider adding an additional field that gets sets to a certain value when a thing’s yes/no 1 field equals its yes/no 2 field, and then you would be able to use one simple constraint to get the things you want.
Hope this helps.
Best…
Mike
Are you able to use advanced filters in backend workflows? And my understanding is that filters, when they’re used, they first pull -all- results forward, so I’m not sure how this is really a useable workaround for most tasks unless you’re already on the client side with a heavily constrained set of data to work with.
Has anyone from Bubble ever explained why something so obvious (and seemingly easy, given this is working with information that is already in context both at the execution end and when creating the expression) isn’t part of the default feature set?
It appears now I’m going to have to figure out yet another layer of precalculation (which is going to make the likelihood of bugs later much more likely, given the data which impacts these comparisons can be modified from two different types of users in two very different settings… keeping all of this in synch is going to be a nightmare just because I can’t test field1 against field2 during a search…)
Well, that, or I just have to change the backend that I use entirely and treat Bubble as a thin layer atop APIs, but at that point, given all the convenience I’d lose in the transition (the fantastic live update/binding and wonderfully simple relationship management), it raises other questions.
Such a shame - I’ve really been loving working with Bubble these last few weeks, even with some of the more severe limitations I’ve had to work around.
An alternative, fully server-side option, (assuming the question is as specific as it seems), is to do a search for things who’s yes/no1 = yes and yes/no 2 is yes, merged with a search for things who’s yes/no 1 is no and yes/no 2 is no.
That will pull all things who’s yes/no 1 and 2 are the same, with a single simple, server-side search.
1 Like
I wish it were that narrow an issue. I need to test five sets of matching booleans, one set of numbers, and a min/max + number set. Crawling over the data that many times just to get around not having access to “test field 1 against field 2” in a single query… I don’t mind paying Bubble for a great tool, but that sounds like throwing money into a wood chipper. 
The limitations for search queries already led to my creating a fact table that draws a bunch of precalculated simplified fields into that table, wiping it clean and creating new records there starting from a broad filter and then narrowing it down as we go. A recursive list-within-a-list set of records to get a full matrix of possible options to test against. I didn’t even consider it would be possible that we can’t test two fields of the same row against one another in a search.
