Looking up one specific Thing ... I feel like I'm misusing Search

Hi all. I can’t shake the feeling that I’m horribly misusing Bubble’s search function, and possibly slowing my app down in the process.

Situation: I need to refer to a specific Thing in a table to retrieve various attributes
Current: I do a “search for” Things from that table that match a specific criteria to uniquely identify the thing that I want, then I finish that off with “:first item” so I am dynamically pulling “Search for Things: first item”
Wondering: Is there some sort of function to just refer to that exact one thing without searching for many things and then limiting it to one? Or is it already doing that and the “:first item” suffix is basically just to complete the Bubble logic statement.

I’m not duplicating searches or anything, I know how to use groups and then refer to the parent group’s search to pull different attributes into different elements – it just seems weird to me to call what I’m doing a “search” and then limit that “search” to the “first item” (or “random item” or “last item”) when I know there’s only one. Like some sort of simpler “lookup” or something.

Am I missing something?

Thanks,

-Ed

I think you’re doing it right. I also do search the way you have described. Have you seen any kind of performance issue or other concern besides the logic flow? To my knowledge there isn’t any “lookup”.

Not necessariliy, but I’m about to have a bunch of users hit it and want to make sure it’s optimized. I’ve got an NCAA-style tournament starting in a week, and the “bracket” page has a bunch of “searches” to pull certain information for each matchup. But again, each search is hyper-specific to that particular matchup.

I feel like I should be just doing ONE search (really just a table reference), and then within that just pointing to an indexed record of data to grab what I need. Seems really inefficient to have 63 individual searches (one for each matchup) on the page. But maybe the way Bubble executes each “search” is just as efficient.

Hmmm… maybe you should put a screenshot of the search you have a concern about just to be sure - 64 searches on the page does sound sub-optimal :slight_smile:

If you know ahead of time how you’re generating the bracket, you should store that info on the objects such that they all can be retrieved from a single search; then the page should be able to display the appropriate data from that single list.

Scott, can you elaborate further? I feel the data are stored optimally. I’m just not sure how to best refer to each Thing from my table in the Bubble UI. I could easily grab all the records and associated data in a single query (and elsewhere in the app, I do). I just don’t know of any other way to say put Item A’s whatever in slot 1, Item B’s whatever in slot 2, Item C’s whatever into slot 3, such that I can effectively display select data from the table like this:

It may be that it’s already pretty efficient for Bubble to handle it as is with all of these “searches”. But it just feels wrong. All I’m really doing is displaying one table’s data in a novel layout. No joins, no transformations, no anything really.

One thing that would theoretically work would be to generalize the search to just grab the Table and use the “:nth item” function, specifying a different value of n for each section of the display. It seems a little loose, because if that view gets distorted in any way it would really mess things up, but perhaps I’ll try it.

How are you currently deciding what gets shown where? I might be able to suggest an alternative once I understand how you’re building the bracket.

It’s pre-specified. So certain Things have to go in certain spots. But a bit more abstractly, there are four “regions” A, B, C, and D; there are six “rounds” 1, 2, 3, 4, 5, and 6, and within each bracket in each round there are n matchups (respectively 8, 4, 2, and then 1). So each matchup is basically “keyed” as 1A1, 1A2, 1A3, … 1D8 … all the way through 4D1 (round 4, bracket d, matchup 1).

So I could sort a general Table search on that key field, and in theory the matchups would be listed in a known order, and I could just point each display element to the right result number using that “:nth item” function.

Maybe that’s what I’ve been looking for … but other thoughts welcome, please.

How many repeating groups are you using to display your data?

As to what @john3 alluded too, this would be useful in knowing. If you are using 64 groups, I would switch it over to repeating groups instead so there’s less elements to work with.

I would design the bracket in the following manner:

  1. the four quadrants would each have a single repeating group, sharing a single datasource
  2. each quadrant would filter the datasource for a particular attribute of your choosing, such as a character in a field, or a new field entirely denoting the round
  3. each subsequent round has it’s own repeating group that would reference the parent-round’s data and filter accordingly via another character or different field (based on how you designed it in step 2)

I think it’s also possible to use a single repeating group for top left and bottom left quadrant; you’ll just have to filter and sort appropriately. Similarly, you can do the same for each subsequent round; therefore, you might be able to get away with as little as 11 repeating groups (including the repeating group that performs the initial query).

1 Like

Right, currently I am using individual groups. I understand the suggestion to switch to repeating groups, but it strikes me as really fickle to try to lay out everything precisely like that. I may give it a try on the outer groups; that would be the biggest bang for the buck by converting eight searches to one, four times (so 32 to 4). And then only have to worry about one alignment.

Thanks for the suggestion. I do still feel like there’s some other more optimal method that isn’t actually possible with Bubble today – to just point to a specific record from a table, referred to by key.

Why does it need to be possible, when :firstitem does exactly this ?

Try it in SQL … SELECT … “LIMIT 1” in MySQL. Just give me the one.

Mongodb has a similar LIMIT parameter.

It just tends to be the way things work in databases. I have to think all the way back to IBM VSAM KSDS to be able to “Get me the row with THIS key”.

That said, there IS a way to directly access a specific thing, you embed the whole thing in another thing using the datatype as a field type. Then you just refer to it, as it is already instantiated for you.

The issue is often that people naturally set up their database for ease of writing (which is rare) rather than ease of access (Which is much more common). Not a bad thing at all, that is why we have star schemes and snowflakes schemas and cubes off the back of our relational data. Relational transaction-based data is often hard to get at.

So it might be worth considering how you would structure your data to make this display as easy as possible. Then see how hard it is to write that data in the first place.

2 Likes

@Scott, yes, the first thing that I tried was the inline (?i), but it did not seem to be working as expected, as noted above.

Though as I try it again now, it does appear to pick up both Hello and hello. I may have placed it incorrectly before. It does not pick up HELLO or crazy case usage like heLLo, but I may be able to live with that. The biggest issue for me was at least getting the capitalized first letter to match usage instances that start a sentence.

Thanks!

Updating this old thread. Thanks to those who offered advice previously. I’ve been going back and optimizing areas of my site that were not performing very well during my March event. Here’s how I optimized this page and the result:

  • Instead of 64 unique (but nearly identical) searches (one for each “bracket segment” that I need to display), I created a new unified search that force-ranked the displayable items based on a certain database field that I can guarantee will maintain order (a systematic “key” if you will).
  • I replicated that same search in each segment, and simply appended :item # after, plus the unique number of each item I need to display in the order I need to display it.

That’s it. The result:

BEFORE: According to Chrome dev tools, this page included three separate searches (one returning 31 results, another returning 31 results, and a final one returning 2 results). Combined they had to wait 11-14 seconds for Bubble to respond.

AFTER: Now it all happens in one search that consistently waits less than 1 second for Bubble to respond. So now the time to render the full page content (essentially just the bracket) is far faster. Huge difference!

-Ed

2 Likes

@edd - so are you using an invisible repeating group for the one unified search?

No repeating group. Still individual groups, each with it’s own search on the surface. But the searches have identical criteria, so it is only run once. Then for display purposes, I grab a different nth result for each group.

How are you able to reference the results of a search without the using a repeating group? Could you share a screen shot?