Can't search on Unique Id in DataTab


Really really?

It seems to be working.

I think interesting things have happened to you. :slight_smile:


Doesn’t appear in here.

Given this is the nearest we have to a “query” in Bubble (something that is a massive gap IMO) it seems odd that you can’t have a Unique ID constraint in here.

Yes, you can search in the main search bar.

While I am at moaning…interesting that Bubble’s data tab is not “responsive” width wise, so no matter how wide your monitor you can’t display any more fields on the data tab.

I got it now. It was difficult to understand from the first post.

I agree with what you said about the data tab, maybe there will be an improvement in the new editor design.

You can use “anyfield” constraint for Unique Id, it works fine.

1 Like

Good call on “anyfield” … but that can show you rows that have relations to that row, rather than the row itself.

When I try on a data type with 13000+ records, I get a single row at a time. So it shows the row itself, not the others that are related.

Also the search is working, maybe a workaround is to search for the unique id after setting the primary fields.

Yes, if your table doesn’t have references to itself.


There really has to be. It is almost impossible to navigate the data tab views if you have multiple “queries”.

Data, and the back end in general (apart from the API Connector) is a real blind spot for Bubble.

In this case too, using two constraints solves the problem.

A new nocode tool will be on the market soon (as a competitor to Xano), they did a demo. It was easy to switch between table and grid views and associated data was easy to see. I hope Bubble adds something similar to this.

That solves a problem I shouldn’t have in the first place :laughing:



Tools like these are going to be the way forward for anything remotely large and needing query/manipulation functions.

I can’t ever think I will use Bubble as a backend again for data as it currently is.

I wish they provide direct SQL requests (read, update). (Bubble uses PostgreSQL).

Completely. Or some other way. It is almost impossible to query the database across complex relations without building a page to show you the data.

And that is using Bubble relations. Trying to import “tables” from another system and then link them with key fields … not really possible at scale. Just tends to time out. But that is how Bubble say you should migrated from another database…but it doesn’t actually work.

Will stop ranting now :flushed: :grinning:

You are absolutely right!

Imagine a product like Tinder.

A user chooses from 1000+ users, likes or rejects. I keep these selections in a different datatype. So I don’t want to show them to the user again. In this case, I have to filter from around 13 000 records (I do it on the server side, not on the browser side), and it takes 8-9 seconds to print this result on the screen.

With the application I mentioned, they proved that it took less than 1 second and they did not even use the caching feature.

But this makes the solution expensive. We use two products instead of one. I hope Bubble can find a solution to these problems with the investments it has received.

1 Like

For a coder like you, another low code product can be a good alternative at some points. Take a look if you want.

1 Like


Every sufficiently complex software product eventually reaches the stage where the is “no going back”.

It would be too hard to rebuild Bubble from scratch and not break things.

It is REALLY hard to move things forward without breaking everything. Editor/Responsive engine/Backend Data/Privacy/Server Side Plugins - they all need attention.

Either that or release Bubble 2.0 :roll_eyes: - then you have two systems to support.

Not at all easy.


My take on the general topic of data definitions, keys, relationships, etc. is that Bubble, at its core, is all about a “no-code” development experience. In my mind, that means the intention is to allow people who don’t have a deep coding background in languages or technologies like SQL DB’s to solve as many use cases as possible. They won’t say this, but it’s not a very good fit (or maybe a better way to say it…“not intended”) for applications that have complex data relationships and therefore complex underlying queries. Code-experienced Bubblers who want the things provided by the various programming languages (Python, Java, C++, R) or database technologies will forever be dealing in workarounds in the Bubble world.

FWIW, I am a huge fan of Bubble for what it does. I love it. But for my app, I don’t rely on the Bubble database much. The SQL Connector is awesome, fast, and lets me handle data complexities through SQL behind the scenes. IMO, it’s a great way to go for apps with complex data requirements.

That said, searching on Unique ID in the data tab isn’t very complex :>

1 Like

Yeah, you are right. But it feels like it shouldn’t be needed.

Maybe I am just too keen to do everything in Bubble as that is where I am comfortable.

This topic was automatically closed after 14 days. New replies are no longer allowed.