-
-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filter source table based on the embedded table(inner join) #197
Comments
Hi @steve-chavez, is this schedule to supabase 2.0? It is a real need 👍🏼 🥇 |
Hey @calebeaires. Yes, I'll work on this for the new postgrest version. |
When can you expect it? @steve-chavez |
+1 - I need this too. |
+1 |
+1 I am looking forward for this so it will get support for https://github.com/supabase/supabase-flutter/ too |
+1 deff need |
+1 - Nextjs + getServerSideProps() |
An update here. This one is already solved at the PostgREST side 🎉 A new release for PostgREST will be made soon, then all Supabase instances will be upgraded to this release. |
@steve-chavez you are my hero! 🥰 |
Can we have an estimated release date? |
waiting for this fix.. by when can we expect this feature? |
Hey everyone Postgrest has launched the new stable 9.0.0 version. Has anyone capable to make a request to update the homebrew formula? |
All Supabase instances have this feature now! https://supabase.com/blog/2021/11/28/postgrest-9#resource-embedding-with-inner-joins |
Thank you for the release! However, I couldn't figure out how to use the !inner keyword in my query:
I have tried something like: |
@rahuldubey093 What's the error message? |
This is the response @steve-chavez It isn't returning any data, even if the rows meet the condition |
@rahuldubey093 What's the result without using the |
@steve-chavez The query returns results but the below conditions don't make any difference: I still get rows where 'connection.beingBlocked' == true |
Ok, so doing final response = await supabase
.from('users')
.select('*, connection:users_connections!users_connections_otherUserUUID_fkey!inner(*)')
.eq('connection.userID', currentUserUID)
.not('connection.beingBlocked', 'eq', true)
.not('connection.blocking', 'eq', true)
.execute(count: CountOption.exact); Are you sure there are rows that fulfill all the conditions? Try by removing some filters and checking the data returned. |
@steve-chavez You are right! Some rows had null values that's why it wasn't working. Now I have made sure none of the rows have null value on the queried columns and the !inner keyword is working as expected! Without the !inner keyword the query was still returning rows which met the conditions. Thank you so much 👍🏻 |
Is the
If I use the For context, if I don't apply any filters my response looks like this (the JSON in this case doesn't include all of the |
@johnhforrest The same For And |
Makes sense, I thought it might have something to do with me misunderstanding the |
Does this work with multiple .or() conditions? I have a quite simple (working) SQL query which needs to be "translated" to Supabase SDK: So by searching for a keyword (e.g. 'Apple') I'd like to query both tables items and manufacturers for their name column. My approach would be something like this, although it doesn't return any value:
However the SQL query works fine so I'm not sure if I have used the !inner correctly? |
No, you cannot apply For that case you'll need a function and call it through rpc. |
Thanks a lot, I have checked rpc. However I'm wondering if this common SQL query (see my previous post) is not possible with Supabase at the moment? Querying two tables (connected by a foreign key) by the conditions with the logical |
You can do
No, as I mentioned above you can't combine OR conditions of different tables. You'll need RPC for this case. |
@steve-chavez One more issue potentially related to this unless it's just a general limitation on supabase requests. I can also open a separate issue to track this if preferred. In the snippet below, This query generates an HTTP 502 response 100% of the time. Here's the error:
If I slice the array to 150 elements, the query works just fine with no other changes. My hunch is that I'm hitting some sort of undocumented limit but 386 is not a huge array and it's certainly not a large request in terms of bytes. Code snippet:
|
does not work with typescript, because in filter it expect only parameter from current table and not from embedded table. |
@johnhforrest I think that might be the URL length limit. See PostgREST/postgrest-docs#417 for a workaround. |
@steve-chavez that was it. Moving to RPC fixed my issue. Thanks! |
How did you do this with RPC? I need to return a JSON response using just the HTTP rest api (using AppGyver). In the docs I only find this: https://[MYSUB].supabase.co/rest/v1/table1?select=some_column,other_table(foreign_key)
Thank you in advance! |
@adrianstoker You need to put the query inside a function: create or replace function my_func() returns setof table("date" date, "time" timestamp/*complete your columns here*/) as $$
SELECT
table1.date,
table1.time,
table1.vehicle
--...
$$ language sql stable; Then call it like:
The REST API will convert it to json automatically. |
join후 column에 접근되지 않는 이슈는 이미 해결 됨. supabase에서 join은 left join으로 인해 filter 자체는 잘 되었지만, filter 값을 제외하고 column에 기본적으로 null 값을 넣기 때문에 filtering이 안 되는 것 처럼 보임. - column 접근 연산자 "->>"에서 "."으로 바꿈 - Resolve commit 06a2ed3 - supabase issue reference => supabase/postgrest-js#197
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:postgrest-js
can detect that the embedded table(users
) filter should also filter the source table(messages
). So, if a row has theusers
attribute asnull
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:
This could also be enabled by default, because is what most users would expect. As mentioned on supabase/supabase#2207:
Drawback
The text was updated successfully, but these errors were encountered: