Hey, I’m trying to filter JOIN statement in WeWeb’s Supabase Plugin.
I have a query like this in SQL
In Supabase I got this far
But when it comes to filtering, it is pretty tough,
Hey, I’m trying to filter JOIN statement in WeWeb’s Supabase Plugin.
I have a query like this in SQL
In Supabase I got this far
But when it comes to filtering, it is pretty tough,
Hey Rob,
There’s 2 things you can do here.
BUT : i don’t like this approach anymore (for perfs). So solution 2 :
I tend to create VIEWs in Supabase
create view myview as select * from table1 join table2 on…
and then use that view as a collection in WeWeb. That’s waaaay faster (according to me anyway).
I hope it helps.
Have a nice night.
Matth-
Hey Matthieu, thanks for your view on the topic
I’m not sure if I can go with views because they dont seem to support row level security. And as for the first proposal, I’m already joining tables with standard joins, but I’m unable to filter the joined result because it gives me back array and then the thitd screenshot happens, with an error also, which is not optimal either, as I can only access the array it seems.
I really appreciate your input though maybe @Alexis would know of a workaround
Basically I’m doing the first one you mentioned but the filter seems to not work on the joined array result, as it treats it as a column for some reason?
Yes they do actually.
If you created your view with the correct syntax, the view will only show what the table can display to your user through the RLS.
drop view public.myview;
create view public.myview with (security_invoker=on) as select………
So yes to views
As for the filters, I have sometimes troubles to filter collections in WeWeb when the first row is not filled with non null values.
I think you have to list what you want for all those tables instead of the stars.
employee_id,
name,
surname,
job: employee_id(job_id, date)
@Alexis seems like it treats the array as a column. It would be fantastic, if instead there were the joined columns, that would be super fantastic : )
Hmm, I might have to use views, but that is not really something I’d be wanting to do like always. As I also cannot filter them directly via a variable. But seems like the only viable option, security invoker is a new thing, isn’t it? Haven’t heard about it before
Edit: Seems like you were right and if this doesn’t get fixed somehow, views will be a good option. Thank you very much for the idea @Matthieu, could you elaborate on the performance concerns regarding the WeWeb “Advanced” WeWeb joins? I thought they were the same. I know there might be some JS behind it all, but in the end it is a call through SDK. Is it that the views are already “ready” there?
I think what is missing is the ability to select a subproperty, or type what you want like “job.date” as field instead of only job
We plan to explore this blocker for the next supabase update
For now I think the only solution is view as @Matthieu suggested
Edit : And for the warning message when putting * symbol in the field, its a false flag, we forgot to handle this case when checking your input
Hey, thanks for the answer! Is there any chance to see what features you have planned and the estimated date? You might want to post it here, so we can add some things that might be missing for us so you can consider adding them
Super late response here but fwiw you can make an API call directly to supabase (not the plugin) using the following PostgREST format.
This example uses an email to look up what orders a particular profile has made (known by a profile_id on the order record, and we search the profiles table by email instead of profile id with an inner join)
*{your supabase url}*/orders?select=*,profiles!inner(email)&profiles.email=eq.test@example.com
/orders
: This is the main endpoint we are querying, meaning we want to retrieve records from the orders
table.select=*,profiles!inner(email)
:*
retrieves all columns from the orders
table.profiles!inner(email)
tells PostgREST to include data from the profiles
table using an inner join on the foreign key.
orders
rows that have a corresponding record in profiles
.(email)
: Specifies that only the email
column from profiles
should be included in the results.profiles.email=eq.test@example.com
:profiles
by email. Only records where profiles.email
matches the specified email will be included, enforcing the filter through the join.The combination of select=*,profiles!inner(email)
with profiles.email=eq...
ensures that:
orders
records with a related profile matching the email are returned.orders
records without a matching profiles
entry, filtering results to exactly what you need.For more info see the PostgREST docs: Resource Embedding — PostgREST 12.2 documentation
Hey, I meanwhile mastered Supabase and wrote a few articles including how to do this effortlessly without involving REST.
Hi all, and hi @Broberto
Many thanks for all these advices such a great job. Also I really appreciate the Weweb team Supabase plugin V2 work @Alexis
I have an error during filtering by a column of a join table that tell me : “column link_events_domaines_invitations.is_actif does not exist”.
My case : I have in Supabase one table named “events”, another named “domaines” and the last for the many to many join implementation named “link_events_domaines_invitations” with “event_id” and “domaine_id” column inside.
So on Weweb side I make a collection and get data from “link_events_domaines_invitations” table like this :
I get well my data like this and more precisly with the “is_actif” column that is located in “events” table :
Now I ty to filter by “is_actif = true” but the error “column link_events_domaines_invitations.is_actif does not exist” is raised :
I can understand this because the “is_actif” column is not directly in my table “link_events_domaines_invitations” where I ask my data but I thought that with the join it will do the job. Am I missing something ? Do I have to make a view ?
Also @Broberto many thanks for your article very interesting. However I didn’t find where you set these filter conditions (during the creation of a collection so in backend filtering or in frontend directly on weweb side ?) :
Regards
Ben
You need to use the workflow actions and a dot notation - foreign_table.column
I think you are talking about the “Database | Select” workflow because I managed to get the data but it seems that the filter is applied after the call so in the front.
Here is my workflow settings :
As you can see the filtered is applied because the “events” data are null in the object 0 and 2 but I would like to not fetch them at all and only have the first object. I think I have to make a view ecause I may have a lot of data in the futur I would like to filter in backend what do you think ?
You need to make it events(event_id) I think. Or events(*) for everything, right?
Both events(*) and events:event_id(*) are working well (just with events:event_id(*) I specify the foreign key name in my source table). events(event_id) raises an error. This has an impact on how you can see your data from the joined table but it does not impact the filtering.
I’m wondering if it can be a bug or we can’t just filter on a column from a joined table on backend side (when filtering during the creation of the collection) @Alexis
I’m going to make a view waiting for weweb answer. Big thanks to you @Broberto for responding so quickly !
I think the view is overall a more sustainable approach