@@ -120,7 +120,9 @@ defmodule AshPostgres do
120120end )
121121
122122changeset =
123- Map . update! ( changeset , :__meta__ , & Map . put ( & 1 , :source , resource . postgres_table ( ) ) )
123+ Map . update! ( changeset , :data , fn data ->
124+ Map . update! ( data , :__meta__ , & Map . put ( & 1 , :source , resource . postgres_table ( ) ) )
125+ end )
124126
125127repo ( resource ) . insert ( changeset )
126128rescue
@@ -148,21 +150,29 @@ defmodule AshPostgres do
148150def sort ( query , sort , _resource ) do
149151{ :ok ,
150152from ( row in query ,
151- order_by: ^ sort
153+ order_by: ^ sanitize_sort ( sort )
152154) }
153155end
154156
155- @ impl true
157+ defp sanitize_sort ( sort ) do
158+ sort
159+ |> List . wrap ( )
160+ |> Enum . map ( fn
161+ { sort , order } -> { order , sort }
162+ sort -> sort
163+ end )
164+ end
156165
157166# TODO: I have learned from experience that no single approach here
158167# will be a one-size-fits-all. We need to either use complexity metrics,
159168# hints from the interface, or some other heuristic to do our best to
160169# make queries perform well. For now, I'm just choosing the most naive approach
161170# possible: left join to relationships that appear in `or` conditions, inner
162- # join to conditions that are constant the query (inner join not functional yet. )
171+ # join to conditions that are constant the query (dont do this yet, but it will be a good optimization )
163172# Realistically, in my experience, joins don't actually scale very well, especially
164173# when calculated attributes are added.
165174
175+ @ impl true
166176def filter ( query , filter , _resource ) do
167177new_query =
168178query