https://supabase.com/ logo
Join Discord
Powered by
It is on the todo list on the repo I believe, but ...
# python
a
It is on the todo list on the repo I believe, but it's not yet implemented (this answers your question as well @User , it's currently not supported yet)
s
https://anand2312.github.io/pgrest/examples/queries/simple-queries/#join-conditions-with-an-orand-clause That's a really elegant interface @User For embedding foreign tables, would it work like this?
Copy code
python
res = await client
.from_("countries")
.select("*,cities(*)")
.where(Column("cities.name") == "Bangkok")
.execute()
a
Thank you! Right, that looks like it should work; although that query might not work exactly how you'd expect. Applying filters on embedded table columns only restricts what values from that embedded table will be returned, and not the top-level table.
For example, in the query you sent, all countries will be included regardless of whether they have an associated city named Bangkok; those countries will just have an empty cities list associated with them
s
True true, and embedded tables conditions don't overlap as well. So how could the 
where
be accommodated for that case? Perhaps having a 
cities_where()
method?
a
I'm a little confused, what case are we trying to cover? 😅
Although having a method like 
cities_where
would need pgrest to know the relationships between tables beforehand and then dynamically make such methods, which would both be a pain to implement and be unclear to end-users
s
> I'm a little confused, what case are we trying to cover? Mostly to make clear that embedded tables filters don't combine inside the same global 
where
Doing:
Copy code
python
.where(Column("cities.name") == "Bangkok" | Column("other.name") == "Stuff" )
) Would be allowed by the interface right? But the `|`(OR) won't work.
> which would both be a pain to implement and be unclear to end-users True, seems painful. 
cities_where
was just an idea.
Maybe the simple way is just to detect that 
Column("cities.name") | Column("other.name")
happens - an embedded table is OR combined with another embedded table - and then err?
a
Ah I get what you mean
I'd expect postgrest itself to send an error response on a query like that
Unsure what error exactly, I'll try it out tomorrow. Some parts of how pgrest currently sends the API requests are rather buggy so I'll be fixing that soon as well
The current version of pgrest just does what postgrest-py does with responses, which is to just return the raw JSON response to the user
A development branch on pgrest has better exception propagation implemented, which would mean that the library would raise an err when the postgrest API sends an error response, like it should in this case
PreviousNext
Powered by