@callback delete(
  struct_or_changeset :: Ecto.Schema.t() | Ecto.Changeset.t(),
  opts :: Keyword.t()
) :: {:ok, Ecto.Schema.t()} | {:error, Ecto.Changeset.t()}

Deletes a struct using its primary key.

If the struct has no primary key, Ecto.NoPrimaryKeyFieldError will be raised. If the struct has been removed prior to the call, Ecto.StaleEntryError will be raised. If more than one database operation is required, they're automatically wrapped in a transaction.

It returns {:ok, struct} if the struct has been successfully deleted or {:error, changeset} if there was a validation or a known constraint error. By default, constraint errors will raise the Ecto.ConstraintError exception, unless a changeset is given as the first argument with the relevant constraints declared in it (see Ecto.Changeset).

Options

• :returning - selects which fields to return. It accepts a list of fields to be returned from the database. When true, returns all fields, including those marked as load_in_query: false. When false, no extra fields are returned. It will always include all fields in read_after_writes. Be aware that the fields returned from the database overwrite what was supplied by the user. Any field not returned by the database will be present with the original value supplied by the user. Not all databases support this option.

• :prefix - The prefix to run the query on (such as the schema path in Postgres or the database in MySQL). This overrides the prefix set in the query and any @schema_prefix set in the schema.

• :stale_error_field - The field where stale errors will be added in the returning changeset. This option can be used to avoid raising Ecto.StaleEntryError.

• :stale_error_message - The message to add to the configured :stale_error_field when stale errors happen, defaults to "is stale".

• :allow_stale - Doesn't error if delete is stale. Defaults to false. This may happen if the struct has been deleted from the database before this deletion or if there is a rule or a trigger on the database that rejects the delete operation.

See the "Shared options" section at the module documentation for more options.

Example

post = MyRepo.get!(Post, 42)
case MyRepo.delete post do
  {:ok, struct}       -> # Deleted with success
  {:error, changeset} -> # Something went wrong
end

@callback delete!(
  struct_or_changeset :: Ecto.Schema.t() | Ecto.Changeset.t(),
  opts :: Keyword.t()
) :: Ecto.Schema.t()

Same as delete/2 but returns the struct or raises if the changeset is invalid.

@callback insert(
  struct_or_changeset :: Ecto.Schema.t() | Ecto.Changeset.t(),
  opts :: Keyword.t()
) :: {:ok, Ecto.Schema.t()} | {:error, Ecto.Changeset.t()}

Inserts a struct defined via Ecto.Schema or a changeset.

In case a struct is given, the struct is converted into a changeset with all non-nil fields as part of the changeset.

In case a changeset is given, the changes in the changeset are merged with the struct fields, and all of them are sent to the database. If more than one database operation is required, they're automatically wrapped in a transaction.

It returns {:ok, struct} if the struct has been successfully inserted or {:error, changeset} if there was a validation or a known constraint error.

Options

• :returning - selects which fields to return. It accepts a list of fields to be returned from the database. When true, returns all fields, including those marked as load_in_query: false. When false, no extra fields are returned. It will always include all fields in read_after_writes as well as any autogenerated id. Be aware that the fields returned from the database overwrite what was supplied by the user. Any field not returned by the database will be present with the original value supplied by the user. Not all databases support this option and it may not be available during upserts. See the "Upserts" section for more information.

• :prefix - The prefix to run the query on (such as the schema path in Postgres or the database in MySQL). This overrides the prefix set in the query and any @schema_prefix set on any schemas. Also, the @schema_prefix for the parent record will override all default @schema_prefixs set in any child schemas for associations.

• :on_conflict - It may be one of :raise (the default), :nothing, :replace_all, {:replace_all_except, fields}, {:replace, fields}, a keyword list of update instructions or an Ecto.Query query for updates. See the "Upserts" section for more information.

• :conflict_target - A list of column names to verify for conflicts. It is expected those columns to have unique indexes on them that may conflict. If none is specified, the conflict target is left up to the database. It may also be {:unsafe_fragment, binary_fragment} to pass any expression to the database without any sanitization, this is useful for partial index or index with expressions, such as {:unsafe_fragment, "(coalesce(firstname, ""), coalesce(lastname, "")) WHERE middlename IS NULL"} for ON CONFLICT (coalesce(firstname, ""), coalesce(lastname, "")) WHERE middlename IS NULL SQL query.

• :stale_error_field - The field where stale errors will be added in the returning changeset. This option can be used to avoid raising Ecto.StaleEntryError.

• :stale_error_message - The message to add to the configured :stale_error_field when stale errors happen, defaults to "is stale".

• :allow_stale - Doesn't error if insert is stale. Defaults to false. This may happen if there are rules or triggers in the database that rejects the insert operation.

See the "Shared options" section at the module documentation for more options.

Examples

A typical example is calling MyRepo.insert/1 with a struct and acting on the return value:

case MyRepo.insert %Post{title: "Ecto is great"} do
  {:ok, struct}       -> # Inserted with success
  {:error, changeset} -> # Something went wrong
end

Upserts

insert/2 provides upserts (update or inserts) via the :on_conflict option. The :on_conflict option supports the following values:

• :raise - raises if there is a conflicting primary key or unique index

• :nothing - ignores the error in case of conflicts

• :replace_all - replace all values on the existing row with the values in the schema/changeset, including fields not explicitly set in the changeset, such as IDs and autogenerated timestamps (inserted_at and updated_at). Do not use this option if you have auto-incrementing primary keys, as they will also be replaced. You most likely want to use {:replace_all_except, [:id]} or {:replace, fields} explicitly instead. This option requires a schema

• {:replace_all_except, fields} - same as above except the given fields are not replaced. This option requires a schema

• {:replace, fields} - replace only specific columns. This option requires :conflict_target

• a keyword list of update instructions - such as the one given to update_all/3, for example: [set: [title: "new title"]]

• an Ecto.Query that will act as an UPDATE statement, such as the one given to update_all/3. Similarly to update_all/3, auto generated values, such as timestamps are not automatically updated. If the struct cannot be found, Ecto.StaleEntryError will be raised.

Upserts map to "ON CONFLICT" on databases like Postgres and "ON DUPLICATE KEY" on databases such as MySQL.

As an example, imagine :title is marked as a unique column in the database:

{:ok, inserted} = MyRepo.insert(%Post{title: "this is unique"})

Now we can insert with the same title but do nothing on conflicts:

{:ok, ignored} = MyRepo.insert(%Post{title: "this is unique"}, on_conflict: :nothing)

Because we used on_conflict: :nothing, instead of getting an error, we got {:ok, struct}. However the returned struct does not reflect the data in the database. If the primary key is auto-generated by the database, the primary key in the ignored record will be nil if there was no insertion. For example, if you use the default primary key (which has name :id and a type of :id), then ignored.id above will be nil if there was no insertion.

If your id is generated by your application (typically the case for :binary_id) or if you pass another value for :on_conflict, detecting if an insert or update happened is slightly more complex, as the database does not actually inform us what happened. Let's insert a post with the same title but use a query to update the body column in case of conflicts:

# In Postgres (it requires the conflict target for updates):
on_conflict = [set: [body: "updated"]]
{:ok, updated} = MyRepo.insert(%Post{title: "this is unique"},
                               on_conflict: on_conflict, conflict_target: :title)

# In MySQL (conflict target is not supported):
on_conflict = [set: [title: "updated"]]
{:ok, updated} = MyRepo.insert(%Post{id: inserted.id, title: "updated"},
                               on_conflict: on_conflict)

In the examples above, even though it returned :ok, we do not know if we inserted new data or if we updated only the :on_conflict fields. In case an update happened, the data in the struct most likely does not match the data in the database. For example, autogenerated fields such as inserted_at will point to now rather than the time the struct was actually inserted.

If you need to guarantee the data in the returned struct mirrors the database, you have three options:

• Use on_conflict: :replace_all, although that will replace all fields in the database with the ones in the struct/changeset, including autogenerated fields such as inserted_at and updated_at:

  MyRepo.insert(%Post{title: "this is unique"},
                on_conflict: :replace_all, conflict_target: :title)

• Specify read_after_writes: true in your schema for choosing fields that are read from the database after every operation. Or pass returning: true to insert to read all fields back. (Note that it will only read from the database if at least one field is updated).

  MyRepo.insert(%Post{title: "this is unique"}, returning: true,
                on_conflict: on_conflict, conflict_target: :title)

• Alternatively, read the data again from the database in a separate query. This option requires the primary key to be generated by the database:

  {:ok, updated} = MyRepo.insert(%Post{title: "this is unique"}, on_conflict: on_conflict)
  Repo.get(Post, updated.id)

Because of the inability to know if the struct is up to date or not, inserting a struct with associations and using the :on_conflict option at the same time is not recommended, as Ecto will be unable to actually track the proper status of the association.

Advanced Upserts

Using an Ecto.Query for :on_conflict can allow us to use more advanced database features. For example, PostgreSQL supports conditional upserts like DO UPDATE SET title = EXCLUDED.title, version = EXCLUDED.version WHERE EXCLUDED.version > post.version. This means that the title and version will be updated only if the proposed row has a greater version value than the existing row.

Ecto can support this as follows:

conflict_query =
  from(p in Post,
    update: [set: [
      title: fragment("EXCLUDED.title"),
      version: fragment("EXCLUDED.version")
      ]],
    where: fragment("EXCLUDED.version > ?", p.version)
  )

MyRepo.insert(
  %Post{id: 1, title: "Ecto Upserts (Dance Remix)", version: 2},
  conflict_target: [:id],
  on_conflict: conflict_query
)

@callback insert!(
  struct_or_changeset :: Ecto.Schema.t() | Ecto.Changeset.t(),
  opts :: Keyword.t()
) :: Ecto.Schema.t()

Same as insert/2 but returns the struct or raises if the changeset is invalid.

@callback insert_all(
  schema_or_source :: binary() | {binary(), module()} | module(),
  entries_or_query ::
    [%{required(atom() | String.t()) => value} | Keyword.t(value)]
    | Ecto.Query.t(),
  opts :: Keyword.t()
) :: {non_neg_integer(), nil | [term()]}
when value: term() | Ecto.Query.t()

Inserts all entries into the repository.

It expects a schema module (MyApp.User) or a source ("users") or both ({"users", MyApp.User}) as the first argument. The second argument is a list of entries to be inserted, either as keyword lists or as maps. The keys of the entries are the field names as atoms, when a schema module is specified in the first argument. Otherwise, the keys can be either atoms or strings representing the names of the columns in the underlying datastore. The value should be the respective value for the field type or, optionally, an Ecto.Query that returns a single entry with a single value.

It returns a tuple containing the number of entries and any returned result as second element. If the database does not support RETURNING in INSERT statements or no return result was selected, the second element will be nil.

When a schema module is given, the entries given will be properly dumped before being sent to the database. If the schema primary key has type :id or :binary_id, it will be handled either at the adapter or the storage layer. However any other primary key type or autogenerated value, like Ecto.UUID and timestamps, won't be autogenerated when using insert_all/3. You must set those fields explicitly. This is by design as this function aims to be a more direct way to insert data into the database without the conveniences of insert/2. This is also consistent with update_all/3 that does not handle auto generated values as well.

It is also not possible to use insert_all to insert across multiple tables, therefore associations are not supported.

If a source is given, without a schema module, the given fields are passed as is to the adapter.

Options

• :returning - selects which fields to return. When true, returns all fields in the given schema. May be a list of fields, where a struct is still returned but only with the given fields. Or false, where nothing is returned (the default). This option is not supported by all databases.

• :prefix - The prefix to run the query on (such as the schema path in Postgres or the database in MySQL). This overrides the prefix set in the query and any @schema_prefix set in the schema.

• :on_conflict - It may be one of :raise (the default), :nothing, :replace_all, {:replace_all_except, fields}, {:replace, fields}, a keyword list of update instructions or an Ecto.Query query for updates. See the "Upserts" section for more information.

• :conflict_target - A list of column names to verify for conflicts. It is expected those columns to have unique indexes on them that may conflict. If none is specified, the conflict target is left up to the database. It may also be {:unsafe_fragment, binary_fragment} to pass any expression to the database without any sanitization, this is useful for partial index or index with expressions, such as {:unsafe_fragment, "(coalesce(firstname, ''), coalesce(lastname, '')) WHERE middlename IS NULL"} for ON CONFLICT (coalesce(firstname, ''), coalesce(lastname, '')) WHERE middlename IS NULL SQL query.

• :placeholders - A map with placeholders. This feature is not supported by all databases. See the "Placeholders" section for more information.

See the "Shared options" section at the module documentation for remaining options.

Source query

A query can be given instead of a list with entries. This query needs to select into a map containing only keys that are available as writeable columns in the schema. This will query and insert the values all inside one query, without another round trip to the application.

Examples

MyRepo.insert_all(Post, [[title: "My first post"], [title: "My second post"]])

MyRepo.insert_all(Post, [%{title: "My first post"}, %{title: "My second post"}])

query = from p in Post,
  join: c in assoc(p, :comments),
  select: %{
    author_id: p.author_id,
    posts: count(p.id, :distinct),
    interactions: sum(p.likes) + count(c.id)
  },
  group_by: p.author_id
MyRepo.insert_all(AuthorStats, query)

Upserts

insert_all/3 provides upserts (update or inserts) via the :on_conflict option. The :on_conflict option supports the following values:

• :raise - raises if there is a conflicting primary key or unique index

• :nothing - ignores the error in case of conflicts

• :replace_all - replace all values on the existing row with the values in the schema/changeset, including fields not explicitly set in the changeset, such as IDs and autogenerated timestamps (inserted_at and updated_at). Do not use this option if you have auto-incrementing primary keys, as they will also be replaced. You most likely want to use {:replace_all_except, [:id]} or {:replace, fields} explicitly instead. This option requires a schema

• {:replace_all_except, fields} - same as above except the given fields are not replaced. This option requires a schema

• {:replace, fields} - replace only specific columns. This option requires :conflict_target

• a keyword list of update instructions - such as the one given to update_all/3, for example: [set: [title: "new title"]]

• an Ecto.Query that will act as an UPDATE statement, such as the one given to update_all/3

Upserts map to "ON CONFLICT" on databases like Postgres and "ON DUPLICATE KEY" on databases such as MySQL.

Return values

By default, both Postgres and MySQL will return the number of entries inserted on insert_all/3. However, when the :on_conflict option is specified, Postgres and MySQL will return different results.

Postgres will only count a row if it was affected and will return 0 if no new entry was added.

MySQL will return, at a minimum, the number of entries attempted. For example, if :on_conflict is set to :nothing, MySQL will return the number of entries attempted to be inserted, even when no entry was added.

Also note that if :on_conflict is a query, MySQL will return the number of attempted entries plus the number of entries modified by the UPDATE query.

Placeholders

Passing in a map for the :placeholders allows you to send less data over the wire when you have many entries with the same value for a field. To use a placeholder, replace its value in each of your entries with {:placeholder, key}, where key is the key you are using in the :placeholders option map. For example:

placeholders = %{blob: large_blob_of_text(...)}

entries = [
  %{title: "v1", body: {:placeholder, :blob}},
  %{title: "v2", body: {:placeholder, :blob}}
]

Repo.insert_all(Post, entries, placeholders: placeholders)

Keep in mind that:

• placeholders cannot be nested in other values. For example, you cannot put a placeholder inside an array. Instead, the whole array has to be the placeholder

• a placeholder key can only be used with columns of the same type

• placeholders require a database that supports index parameters, so they are not currently compatible with MySQL

@callback insert_or_update(changeset :: Ecto.Changeset.t(), opts :: Keyword.t()) ::
  {:ok, Ecto.Schema.t()} | {:error, Ecto.Changeset.t()}

Inserts or updates a changeset depending on whether the struct is persisted or not.

The distinction whether to insert or update will be made on the Ecto.Schema.Metadata field :state. The :state is automatically set by Ecto when loading or building a schema.

Please note that for this to work, you will have to load existing structs from the database. So even if the struct exists, this won't work:

struct = %Post{id: "existing_id", ...}
MyRepo.insert_or_update changeset
# => {:error, changeset} # id already exists

Options

• :prefix - The prefix to run the query on (such as the schema path in Postgres or the database in MySQL). This overrides the prefix set in the query and any @schema_prefix set any schemas. Also, the @schema_prefix for the parent record will override all default @schema_prefixs set in any child schemas for associations.
• :stale_error_field - The field where stale errors will be added in the returning changeset. This option can be used to avoid raising Ecto.StaleEntryError. Only applies to updates.
• :stale_error_message - The message to add to the configured :stale_error_field when stale errors happen, defaults to "is stale". Only applies to updates.
• :allow_stale - Doesn't error if delete is stale. Defaults to false. Only applies to updates.

See the "Shared options" section at the module documentation for more options.

Example

result =
  case MyRepo.get(Post, id) do
    nil  -> %Post{id: id} # Post not found, we build one
    post -> post          # Post exists, let's use it
  end
  |> Post.changeset(changes)
  |> MyRepo.insert_or_update

case result do
  {:ok, struct}       -> # Inserted or updated with success
  {:error, changeset} -> # Something went wrong
end

@callback insert_or_update!(changeset :: Ecto.Changeset.t(), opts :: Keyword.t()) ::
  Ecto.Schema.t()

Same as insert_or_update/2 but returns the struct or raises if the changeset is invalid.

@callback load(
  schema_or_map :: module() | map(),
  data :: map() | Keyword.t() | {list(), list()}
) :: Ecto.Schema.t() | map()

Loads data into a schema or a map.

The first argument can be a schema module or a map (of types). The first argument determines the return value: a struct or a map, respectively.

The second argument data specifies fields and values that are to be loaded. It can be a map, a keyword list, or a {fields, values} tuple. Fields can be atoms or strings.

Fields that are not present in the schema (or types map) are ignored. If any of the values has invalid type, an error is raised.

To load data from non-database sources, use Ecto.embedded_load/3.

Examples

iex> MyRepo.load(User, %{name: "Alice", age: 25})
%User{name: "Alice", age: 25}

iex> MyRepo.load(User, [name: "Alice", age: 25])
%User{name: "Alice", age: 25}

data can also take form of {fields, values}:

iex> MyRepo.load(User, {[:name, :age], ["Alice", 25]})
%User{name: "Alice", age: 25, ...}

The first argument can also be a types map:

iex> types = %{name: :string, age: :integer}
iex> MyRepo.load(types, %{name: "Alice", age: 25})
%{name: "Alice", age: 25}

This function is especially useful when parsing raw query results:

iex> result = Ecto.Adapters.SQL.query!(MyRepo, "SELECT * FROM users", [])
iex> Enum.map(result.rows, &MyRepo.load(User, {result.columns, &1}))
[%User{...}, ...]

@callback preload(structs_or_struct_or_nil, preloads :: term(), opts :: Keyword.t()) ::
  structs_or_struct_or_nil
when structs_or_struct_or_nil: [Ecto.Schema.t()] | Ecto.Schema.t() | nil

Preloads all associations on the given struct or structs.

This is similar to Ecto.Query.preload/3 except it allows you to preload structs after they have been fetched from the database.

In case the association was already loaded, preload won't attempt to reload it. Preload assumes each association has the same nested associations already loaded. If this is not the case, it is possible to lose information. For example:

comment1 = TestRepo.preload(comment1, [author: [:permalink]])
TestRepo.preload([comment1, comment2], :author)

If both comments are associated to the same author, the first comment will lose its nested :permalink association because the second comment does not have it preloaded. To avoid this, you must preload the nested associations as well.

If you want to reset the loaded fields, see Ecto.reset_fields/2.

Options

• :force - By default, Ecto won't preload associations that are already loaded. By setting this option to true, any existing association will be discarded and reloaded.
• :in_parallel - If the preloads must be done in parallel. It can only be performed when we have more than one preload and the repository is not in a transaction. Defaults to true.
• :prefix - the prefix to fetch preloads from. By default, queries will use the same prefix as the first struct in the given collection. This option allows the prefix to be changed.
• :on_preloader_spawn - when preloads are done in parallel, this function will be called in the processes that perform the preloads. This can be useful for context propagation for traces.

See the "Shared options" section at the module documentation for more options.

Examples

# Use a single atom to preload an association
posts = Repo.preload posts, :comments

# Use a list of atoms to preload multiple associations
posts = Repo.preload posts, [:comments, :authors]

# Use a keyword list to preload nested associations as well
posts = Repo.preload posts, [comments: [:replies, :likes], authors: []]

# You can mix atoms and keywords, but the atoms must come first
posts = Repo.preload posts, [:authors, comments: [:likes, replies: [:reactions]]]

# Use a keyword list to customize how associations are queried
posts = Repo.preload posts, [comments: from(c in Comment, order_by: c.published_at)]

# Use a two-element tuple for a custom query and nested association definition
query = from c in Comment, order_by: c.published_at
posts = Repo.preload posts, [comments: {query, [:replies, :likes]}]

The query given to preload may also preload its own associations.

@callback reload(
  struct_or_structs :: Ecto.Schema.t() | [Ecto.Schema.t()],
  opts :: Keyword.t()
) :: Ecto.Schema.t() | [Ecto.Schema.t() | nil] | nil

Reloads a given schema or schema list from the database.

When using with lists, it is expected that all of the structs in the list belong to the same schema. Ordering is guaranteed to be kept. Results not found in the database will be returned as nil.

Example

MyRepo.reload(post)
%Post{}

MyRepo.reload([post1, post2])
[%Post{}, %Post{}]

MyRepo.reload([deleted_post, post1])
[nil, %Post{}]

@callback reload!(struct_or_structs, opts :: Keyword.t()) :: struct_or_structs
when struct_or_structs: Ecto.Schema.t() | [Ecto.Schema.t()]

Similar to reload/2, but raises when something is not found.

When using with lists, ordering is guaranteed to be kept.

Example

MyRepo.reload!(post)
%Post{}

MyRepo.reload!([post1, post2])
[%Post{}, %Post{}]

@callback update(changeset :: Ecto.Changeset.t(), opts :: Keyword.t()) ::
  {:ok, Ecto.Schema.t()} | {:error, Ecto.Changeset.t()}

Updates a changeset using its primary key.

A changeset is required as it is the only mechanism for tracking dirty changes. Only the fields present in the changes part of the changeset are sent to the database. Any other, in-memory changes done to the schema are ignored. If more than one database operation is required, they're automatically wrapped in a transaction.

If the struct has no primary key, Ecto.NoPrimaryKeyFieldError will be raised.

If the struct cannot be found, Ecto.StaleEntryError will be raised.

It returns {:ok, struct} if the struct has been successfully updated or {:error, changeset} if there was a validation or a known constraint error.

Options

• :returning - selects which fields to return. It accepts a list of fields to be returned from the database. When true, returns all fields, including those marked as load_in_query: false. When false, no extra fields are returned. It will always include all fields in read_after_writes. Be aware that the fields returned from the database overwrite what was supplied by the user. Any field not returned by the database will be present with the original value supplied by the user. Not all databases support this option.

• :force - By default, if there are no changes in the changeset, update/2 is a no-op. By setting this option to true, update callbacks will always be executed, even if there are no changes (including timestamps).

• :prefix - The prefix to run the query on (such as the schema path in Postgres or the database in MySQL). This overrides the prefix set in the query and any @schema_prefix set on any schemas. Also, the @schema_prefix for the parent record will override all default @schema_prefixs set in any child schemas for associations.

• :stale_error_field - The field where stale errors will be added in the returning changeset. This option can be used to avoid raising Ecto.StaleEntryError.

• :stale_error_message - The message to add to the configured :stale_error_field when stale errors happen, defaults to "is stale".

• :allow_stale - Doesn't error if update is stale. Defaults to false. This may happen if the struct has been deleted from the database before the update or if there is a rule or a trigger on the database that rejects the update operation.

See the "Shared options" section at the module documentation for more options.

Example

post = MyRepo.get!(Post, 42)
post = Ecto.Changeset.change post, title: "New title"
case MyRepo.update post do
  {:ok, struct}       -> # Updated with success
  {:error, changeset} -> # Something went wrong
end

@callback update!(changeset :: Ecto.Changeset.t(), opts :: Keyword.t()) :: Ecto.Schema.t()

Same as update/2 but returns the struct or raises if the changeset is invalid.