I’m wondering if I understand the Ecto.insert :returning option. Here’s how I think it works when inserting a changeset (and possibly a schema struct - I haven’t checked): Regardless of :returning, the input :data is returned, including virtual fields. Regardless of :returning, the primary key is …

The following appears to be true, and I’ll make a pull request against the documentation (better written than the below). By default, insert receives only the new primary key (typically, :id) from the database. That id is merged with the data given to insert to produce what is usually a copy of the…

[image] marick: Is that right? Ecto.Repo — Ecto v3.14.0 :returning - selects which fields to return. It accepts a list of fields to be returned from the database. When true , returns all fields. When false , no extra fields are returned. It will alwa…

The raw SQL looks like this: INSERT INTO "demo"."service_gaps" ("gap","reason") VALUES ($1,$2) RETURNING "id"... ^^^^^^^^^^^^^ … for all of these cases: ... |> Crit.Repo.insert(prefi…

Changesets already hold all the data needed to return you the inserted value. :returning similar to :read_after_writes is only useful if your db has autogenerated values, defaults, triggers or such means to modify the value you’re persisting and you want to read it back, because what the changeset h…

[image] marick: only the new primary key is provided. And any fields that have :read_after_writes set to true - they are essentially treated the same as the autogenerated id. Ecto.Schema — Ecto v3.14.0 :read_after_writes - When true, the field is alw…

[image] peerreynders: What the documentation isn’t explicit about (likely assumed by implication) is that the returned values will replace the original values in the changeset :data . Correct.

How Ecto.insert(..., returning: ...) works

Questions & Help Questions

josevalim September 22, 2019, 6:28pm 7

Correct.