@@ -90,6 +90,11 @@ defmodule AshPostgres do
9090{ :ok , from ( row in query , offset: ^ offset ) }
9191end
9292
93+ @ impl true
94+ def run_query ( % { __impossible__: true } , _ ) do
95+ { :ok , [ ] }
96+ end
97+
9398@ impl true
9499def run_query ( query , resource ) do
95100{ :ok , repo ( resource ) . all ( query ) }
@@ -134,7 +139,9 @@ defmodule AshPostgres do
134139# hints from the interface, or some other heuristic to do our best to
135140# make queries perform well. For now, I'm just choosing the most naive approach
136141# possible: left join to relationships that appear in `or` conditions, inner
137- # join to conditions in the mainline query.
142+ # join to conditions that are constant the query (inner join not functional yet.)
143+ # Realistically, in my experience, joins don't actually scale very well, especially
144+ # when calculated attributes are added.
138145
139146def filter ( query , filter , _resource ) do
140147new_query =
@@ -143,7 +150,14 @@ defmodule AshPostgres do
143150|> join_all_relationships ( filter )
144151|> add_filter_expression ( filter )
145152
146- { :ok , new_query }
153+ impossible_query =
154+ if filter . impossible? do
155+ Map . put ( new_query , :__impossible__ , true )
156+ else
157+ new_query
158+ end
159+
160+ { :ok , impossible_query }
147161end
148162
149163defp join_all_relationships ( query , filter , path \\ [ ] ) do
@@ -305,7 +319,7 @@ defmodule AshPostgres do
305319end )
306320
307321Enum . reduce ( filter . ors , { params , expr } , fn or_filter , { params , existing_expr } ->
308- { params , expr } = filter_to_expr ( or_filter , bindings , params )
322+ { params , expr } = filter_to_expr ( or_filter , bindings , params , current_binding , path )
309323
310324{ params , join_exprs ( existing_expr , expr , :or ) }
311325end )