Hello! New to Glide and excited to engage with the community and hopefully eventually give back some
I have two primary tables:
users (name, email, etc.)
products (name, description, etc.)
I’ve connected them with a user_product table which creates a row each time a user makes an election on a product (e.g., user A said “yes” to product A).
In the screen I’m building, I’m essentially trying to show all of user A’s “yes” election products on a screen, and all the underlying data from the product table.
I’ve tried two routes:
If I start building this screen from the products table, I can’t seem to filter with the user_product table, and it doesn’t feel right to bring user dimensions into that product table.
If I start with the user_product table, I can effectively filter for “yes” only products, but the columns I’d like from the product table aren’t available to use. Perhaps I need to bring all the relevant product fields over via relation columns into the user_product table for this to work? Just feels redundant if the association is already there…
@Darren_Murphy thanks, see above! So I’m trying to get a page of product columns that I can filter based on which products the user (josh) accepted (election column).
Add a RowD column to your Users table, and use that as a UserID
Add a RowID column to your Products table, and use that as a ProductID
In your UserProduct table, instead of storing User Name & Product Name, store the respective ID values for each.
Taking the above approach will make for a much more robust solution, which wont be subject to breakage if/when User or Product names are changed.
Now, to the challenge at hand:
I think what you are looking for here is something we refer to as Inline Lookups, which unfortunately aren’t available in Glide (a long standing feature request, but that’s a separate story).
So yes, essentially what you need to do is create relations to link the tables - as I can see you’ve already started doing - and then use lookup columns to bring in any related data that you need.
This might feel like data redundancy, but it isn’t really. These are computed columns that cost nothing - there still remains a single source of truth in each of the respective tables.
Many different ways you can approach this. Can we assume that the user (Josh) will be the currently signed in user, or could it be any user that has been selected from a list of users?
Yes, I know I haven’t given you a direct answer yet, but I’m working my way to it
@Darren_Murphy I think it actually works well when I put more product columns into the user_product table like you suggested. Then I can base the whole page/tab on that user_product table and can thus leverage the filtering columns I need. I think I’m good?! Thanks again. I’m sure I’ll have another question in a matter of hours here
