Trying to make sense of matching two lists in a backend workflow! Help!

Hi all, I’ve been learning as I go after following one of bubble’s online courses and am trying to solve a problem that I just can’t wrap my head around.

I have two lists on two separate data types (user and advert) they both feed from the same separate data type, a user has multiple things they want and an advert may be selling multiple things. So I want to match any entries and return the advert so the user knows have at least a partial match on their watch list.

e.g.

Data type - parts
user - list of parts

advert - list of parts

Parts data type contains all parts to sell; A - Z.

User might require parts A,B,C
Advert might be listing parts C,D,E

I’d like to return the advert as they both have at least one match.

I’ve been trying for ages, have tried to play around with intersect but can’t seem to get that to work either. Any help would be greatly appreciated.

Thanks

Intersect works fine, you just have to have a look at your privacy rules. The current user can only view their data by default. See the example below.

Example

Thanks very much for your reply and example. It makes sense, but i missed a critical bit of detail; I’m wanting to run this in a back end workflow to minimise front end processing and to make allowances for future scale.

I’ve passed through the adverts list of parts, and can search for the users list as well. But can’t figure out where to place the calculation (i’m guessing into the ‘only when’ on the backend API event trigger).

Appreciate your assistance.

I have updated it to show how a workflow would work from a button click. You would have to setup a backend workflow that takes in a list of adverts and then returns adverts that align to a given user.

For scale you have to restructure your database instead of using parts as a list on user and advert.
Option 1: Add advert_id and user_id for each part which will store the unique ids of user and advert. Then you can search for part where the unique id of advert/ user is equal to the given user/advert.

Option 2: Make a third table that with part_id, id and type. Where type can be advert/user, id will be the unique id of the id of the user/advert and part_id will be the unique id of the part.

Having list types will degrade performance once the amount of parts increase and with the repeating group added you can see that I intersect first the parts for user and adverts and then have to do a secondary search to find the adverts that have those parts. Additionally, you would also have to add functionality to separate the adverts that have the same part.

1 Like

Thanks for this. it definitely got me pointed in the right direction and helped me get the workflow set up correctly in the backend.

Thanks again

1 Like

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