Dumb recommendation system by matching lists

Was trying to build a pretty simple dumb recommendation system by matching a Thing to other Thing’s through a list of “tags”. I’ve been at this for a few hours now and have hit a brick wall.


Thing “photo” with list field “tags”

Photo A has a list of “tags” - cat, dog, horse
Photo B has a list of “tags” - horse, monkey

When I’m displaying Photo A, I want to also display photo B as a “you might also like…”
because Photo B and Photo A both have a tag named “horse”

Doing something like a RG set to display “photo” and search for photo’s tags contains Photo A’s tags requires the full list to be the same. So I read somewhere on the forum that the function “contains list” is the way to go to cross compare two list for any match. However, using “contains list” simply shows me all entries in the database with a blatant disregard for what’s in the “tags” lists.

The ever so slightly useful documentation explains “contains list” as such,

… contains list …

Returns yes if the first list contains all the entries from the second list.

What I’m looking for is a function to search the second list for any of the entries in the first list, and spit out all the Things that have lists with one or more matching animal in it’s list.

Now, it would of course be even cooler if you could then weight this in the sorting by how many similar tags a thing has… but I’m getting greedy here.

Perhaps none of this is possible, perhaps it’s super easy and I’ve just been away from Bubble for too long to remember, or perhaps this is a case where I need @keith’s powerful listshifter, that I can never seem to wrap my head around. :crazy_face: < me trying to use listshifter

Hi there, @casheets123… if I understand your post correctly, I have done what you described by using an advanced filter to compare two lists with the intersect with option, and then you do a :count > 0 at the end of the query. So, the query determines if there is any intersection between the two lists by doing a count of like items and stopping as soon as that count is greater than 0. Hmm, you might even be able to do something with weighting by requiring the count of like items to be greater than some number greater than 0, but I would have to play around with that idea to know for sure.

Here is an example of such a query that I posted in another thread…

Hope this helps.



On the question of whether it’s possible to sort by # of intersects, some threads here grapple with it. I haven’t spent enough time to get to the bottom of it, but it’s on my to do list.

1 Like

@mikeloc @ed727

Ah yes of course! Intersect is what I’m looking for! :heart: thank you guys. I will have a look at the thread about weighting the result. Theoretically there should be a way… in bubble practice, there might not be or be very difficult to achieve.

1 Like

Here’s a “dumb” way to do it that I just tried. I wanted to produce a list ranked (ie sorted) by the # of matches. The problem is that the # of matches (the count of the intersect) is a calculated field, and Bubble doesn’t let you sort on it.

The workaround is you create some hidden RGs each to do the intersect with search, and you set the count to = the # of intersects. So the first hidden RG has anything with 1 intersect, the second has anything with 2, and so forth. Keep creating hidden RGs up until the # of intersects you think would be the max (within reason, and then just use > to capture the rest).

Then for the matches you show, use the “merged with” function to pull those hidden RG lists together into a new RG in the order you want them. I just tried it, and it merged them in the exact order that I asked for them. So let’s say that you have 4 hidden RGs as follows: 4+ matches, 3 matches, 2 matches and 1 match. Using the merged with in that order produced a list in that order.

Caveat is that the intersect with is an advanced filter and it’s not fast on a large dataset since it’s executed client side, so imagine executing multiple of them at one time.

PS: note that I learned you can execute intersect with server side using an api workflow, which should be faster. Gaby wrote about that process in her VIP course which requires a monthly subscription.

1 Like

Hmm, yeah that would be one way of doing it, but it would scale extremely poorly as you point out. I’m also by pure grumpy-ness opposed to use the popular hidden RG hack haha. It just never sat right with me.

But, I wonder if this is a case where @gaurav’s BDK live sorting idea could work? I don’t have the plug in installed. I have no idea how that plug in works or what it does I just remember seeing it in a thread a long time ago. I’m thinking perhaps one hidden RG could display a number with all matches and a number of intersecting hits per cell, and then a second visible RG to sort on the numbers in the first, hidden, RG? What do you think @gaurav? At least that would remove the need for multiple hidden RG groups.

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