Why does Bubble restrict DO A SEARCH FOR constraints?

[markeaston]

I wonder why Bubble restricts the DO A SEARCH FOR constraints to only 1 level of database.

Eg. I would love to ‘do a search for’:

Thing A database:

Constraints:

1. Thing A’s name is xxxx
2. Thing A’s Thing B’s ‘category’ is 4

I want to find Thing A’s that have Thing B’s ‘category’ number 4 (Thing A is related to Thing B by the way).

As it stands Bubble doesn’t allow the second database within the ‘constraints’, you are forced to ‘look’ only as deep as Thing A’s datafields.

Currently my only workaround is to create a ‘category’ field in Thing A’s database which is set as Thing B’s category. But as we all know, duplicate data is a no-no. These workarounds are ok but when you get to complex scheduled API’s this doesn’t help. It also requires ‘resetting’ Thing A’s category should Thing B’s category change. You get my drift in a Dr Seuss type of way?

Anyone else asked Bubble to look at this? Certainly would make API’s cleaner and more reliable.

Sorry it’s on the ‘Need Help’ section but there isn’t a ‘suggestions box’ as far as I know.

[boston85719]

This has been a request for years, a known issue with existing work arounds and plugins that solve for it as best can by community members. Until bubble changes codebase, it’s all we can do.

I think somebody posted same exact topic a day or two ago, so clearly a concept many have had to wrangle with on bubble.

Can we eliminate anti-patterns from Bubble?

One of the things that really pisses me off about Bubble is the amount of antipatterns that are required to build basic functionality. One example is showing results in a searchbox. Let’s say you have a Company and Product and you want the searchbox results to show Company - Product. To do this, you have to create a new field, duplicate the data from two fields onto that new field, then use that as the search result. This runs contrary to general good practices and creates an enormous amount of …

But for your use case, why not search for Thing b by status and select thing b thing A to show all thing A whose thing B is the status to show, if your thing B has a related field of thing A? 1 to 1 relationships can help the way in which we search and filter to find the data we are looking for

[markeaston]

thanks boston: that’s a great idea. I don’t often use 1 to 1 but that works. I’ll need a little re-engineering to save a list of Thing A’s in Thing B but that’s ok. Many thanks for the help.

[adamhholmes]

@markeaston

Constraints:

1. Thing A’s name is xxxx
2. Thing A’s Thing B’s ‘category’ is 4

I want to find Thing A’s that have Thing B’s ‘category’ number 4 (Thing A is related to Thing B by the way).

You can do this with a nested search

i.e. Constraints:

1. Thing A’s name is xxxx

2. Thing A’s Thing B is in [search for Thing Bs where Category is 4]

It’s not as efficient as adding a redundant field, but it prevents the need for data denormalisation - so depending on the size of data, it’s often a good alternative.

[markeaston]

thanks adam: yes I see what you mean. The adding of a field of ‘category’ to Thing A’ that matches the category in Thing B is a smaller WU use than having to add every Thing A to Thing B. Hmmm, something to think about. The Thing A records will be a fair bit more than the Thing B (the group)