This is a common use case. Examples:
For solving that on the backend, PostgREST/postgrest#1075 needs to be cleared.
Currently the users need to work around this on the client side.
Alternative
However, an alternative could be doing the filtering on postgrest-js itself. When a user does this:
await supabase
.from('messages')
.select('id, user_id, users(id, username)')
.filter('users.username', 'eq', 'Calebe')postgrest-js can detect that the embedded table(users) filter should also filter the source table(messages). So, if a row has the users attribute as null or [], then the whole row can be filtered. Check the example on supabase/supabase#2207 (comment) for sample outputs.
To enable this mode, an option to filters could be added. Like:
eq('users.username', 'Calebe', {filterSource: true})
// or perhaps as "inner", that would reflect what postgrest would do eventually
eq('users.username', 'Calebe', {inner: true})This could also be enabled by default, because is what most users would expect. As mentioned on supabase/supabase#2207:
"I expected more atomic results considering the filter will exclude the result at the primary level."
Drawback
"I can't use this approach on the table that could lead to big dataset."
This is a common use case. Examples:
For solving that on the backend, PostgREST/postgrest#1075 needs to be cleared.
Currently the users need to work around this on the client side.
Alternative
However, an alternative could be doing the filtering on
postgrest-jsitself. When a user does this:postgrest-jscan detect that the embedded table(users) filter should also filter the source table(messages). So, if a row has theusersattribute asnullor[], then the whole row can be filtered. Check the example on supabase/supabase#2207 (comment) for sample outputs.To enable this mode, an option to filters could be added. Like:
This could also be enabled by default, because is what most users would expect. As mentioned on supabase/supabase#2207:
Drawback