thojanssens1
This will work:
Repo.insert!(
%Vote{
user_id: user_id,
input_id: hd(input_ids)
},
prefix: Triplex.to_prefix(tenant)
)
Query generated:
INSERT INTO “localhost”.“votes” (“input_id”,“user_id”,“id”,“inserted_at”,“updated_at”) VALUES ($1,$2,$3,$4,$5)
This won’t:
new_votes =
[
%{
input_id: "2c92c315-b81f-413e-8014-b7a0ab2038a6",
user_id: "2dd65dcd-9741-4075-943c-c372c8a2ae97"
}
]
Ecto.Multi.new()
|> Ecto.Multi.delete_all(:delete_votes, delete_votes_query, prefix: Triplex.to_prefix(tenant))
|> Ecto.Multi.insert_all(:insert_all, Vote, new_votes, prefix: Triplex.to_prefix(tenant))
|> Repo.transaction()
Error:
** (Postgrex.Error) ERROR 23502 (not_null_violation) null value in column “id” violates not-null constraint
table: votes
column: id
Query generated:
INSERT INTO “localhost”.“votes” (“input_id”,“user_id”) VALUES ($1,$2)
I do not understand why Ecto.Multi.insert_all doesn’t generate id and timestamp columns like Repo.insert! does.
In the Vote schema we have:
@primary_key {:id, Ecto.UUID, autogenerate: true}
deps: {:ecto_sql, "~> 3.1"}
Any help?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #blog-post
- #ai
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
The ID thing is definitely weird, but the timestamps not being generated is documented behavior:
There’s this thread that describes almost exactly the same issue, but what needed to change to make the problem go away isn’t clear
fuelen
IDs generation can be moved to the database level. Postgres has great
uuid-osspextension. Enable it, set the default value for id column touuid_generate_v4()and use@primary_key {:id, Ecto.UUID, read_after_writes: true}.thojanssens1
See docs in link below mentioning that UUID are actually purposely not autogenerated:
https://github.com/elixir-ecto/ecto/commit/99dff4c4403c258ea939fe9bdfb4e339baf05e13
LostKobrakai
The
*_allfunctions in ecto deal with queries and plain values, but not schemas. Even if you supply a schema module, it’s only used for building an query (they’reEcto.Queryable’s).Given all the timestamp and autogenerate stuff is defined for schemas, those functions don’t know about those things and therefore can’t handle them.
thojanssens1
Thank you. But then I still wonder what’s the reason that we don’t have a version of those
*_allfunctions that “do more”/“are smarter” (e.g. autogenerate an UUID), in addition to the lower-level ones (allowing then to avoid usinginsertin anEnum.eachif you want to use Schema’s configs).Also why are specifically the
*_allfunctions lower-level at all, as opposed to other functions? I don’t grasp the design choices.LostKobrakai
Likely because they can’t do everything.
Repo.insertcan deal with assocs, which requires it to run multiple queries. All the*_allfunctions run just a single sql query, so they cannot support associations at all. So instead of opting for the vague middleground of supporting some schema based features and not others they simply support non of them. This is besides the fact that those functions are meant to work without needing schemas in the first place.thojanssens1
It’s still hard for me to see why we can’t take into account the auto generated fields if an Ecto schema is passed as first argument. This is not related to associations. If I change my timestamp from naivedatetime to datetime, now I have to change the code using
insert_alland such functions, or (less likely) if I change the type of id.I can live with it though.
LostKobrakai
The “IF an Ecto Schema is passed…” is exactly why.
Supporting only a subset of schema based functionality of only a subset of possible arguments to
*_allfunctions will be even more confusing than just saying: sorry all the schema stuff is not supported here. Besides the fact the implementation of the latter is likely way simpler to maintain.Basically
*_allfunctions are build to supportRepo.insert_all("table", [%{id: 1}])– maybe even more thanRepo.insert_all(MySchema, [%{id: 1}]).Repo.insertis the other way round. It supports only schemas, but not plain queries.thojanssens1
Could we mention one concrete example of a schema functionality (among the whole set of schema functionalities) that would be confusing for not to be supported in the case that support for field generation (id/timestamps) is added?
LostKobrakai
With fields on schemas you can alter the column name of a field:
Repo.insert_all(MySchema, [%{test: "value 1", old_legacy_name: "value 2"}]What would this do under the assumption the function would work with schema functionality?