Possible bug in filtering (or strange behavior)

[adamhholmes]

I’ve noticed something slightly odd, and I’m not sure if it’s a bug, or if it’s just the way Bubble works, so I though I’d ask here…

I’m working on a search feature and applying some filters to a list of data to display in a repeating group, and using the ‘Contains’ constraint to filter the data.

I’ve notice that when I’m using this constraint on a filed that is a single entry, the filtered results will display things in which the specified filed contains the data entered in the constraint…

For example, if I use ‘First Name’ contains ‘fran’, then things with firstnames such as ‘Frank’, ‘Francis’, ‘Francesca’ etc. will be displayed, as they all contain the constraint value.

However, if the field in question is a list (i.e. a list of texts), then the ‘contains’ constraint only shows items that match entirely.

For example, if filtering based on a field which is a list of texts, if I use ‘Tags’ contains ‘design’, I would expect to see things with ‘tags’ including things like ‘UX Design’, ‘Graphic Design’, ‘Web Design’ etc.

But I’m not. In this case I’m only seeing things which match exactly ‘design’ so would have to filter for ‘Ux Design’ to see those tags specifically.

It seems strange to me why the same constraint should work differently on a field depending on whether it’s a single entry or a list, so was wondering if it’s a bug - or just the way Bubble handles and filters lists.

Anyone has any thoughts or experience of this?

[cmarchan]

A list containts objects. A text is a text.

[buckman]

Hi @adamhholmes
Have you tried to search using proper case? I’ve experienced where bubble recognizes upper and lower case in a search. Could this be part of the problem? Try to search for [capitalized]Design and see if that does anything for you.
Buck

[adamhholmes]

Hi @buckman yes, I was having issues with ‘case’ as well but managed to solve that with a similar workaround to what you suggest (using lowercase).

Another interesting point I found was that when using the ‘Any Field - Contains’ search constraint, case is irrelevant and ignored. But when using any ‘Specific Field - Contains’ then the search is case sensitive, and has to be dealt with as you suggest above.

And another slightly annoying point - in the search and standard filter options, you’re able to adjust the ‘search constraint’ to lowercase (or upper case, capitalized etc.) but not the initial field data.

FirstName' - contains - 'Search Input' - lowercase

Whereas in the advance filter option you can set the initial field to lowercase (or any other case) but NOT the search input field:

'FirstName' - lowercase - contains - 'Search Input'

Obviously, ideally you would be able to set the case for both - it seems strange that you cant. There’s a workaround of course - setting either a custom state or an element data source to be the value of the search input converted to lowercase, and then using an advanced filter to change the filtered field to lowercase. It works fine, but is a little bit slower.

Regarding my original question, the issue is more about the type of search match…

For a single entry field the search works for partial searches - i.e. 'searching for ‘pepp’ will return peppers.

But for fields that are lists, the search does not work for partial words, and only shows results that are exact matches to the search term.

I was wondering if it was something to do with the recent change from ‘Contains’ to ‘Contains Keyword’ that was rolled out in August, as the differences here are the same as the differences between those 2 options.

Perhaps it wasn’t applied to list fields for some reason.