tompave
Proposal: prepare_query for write operations
Hello,
This is a question about Ecto’s prepare_query/3 callback. Specifically, on the fact that it only works for the “Query API” (all, get, one, aggregate and friends).
I can’t find any detailed information on why it doesn’t support the “Schema API”, which mostly contains write operations.
I’ve found a couple of GitHub issues (issues/3608 and issues/3702) where this was briefly discussed, but nothing was said on the why. I’ve also found this old topic here on the forum, which however didn’t receive any replies.
At the moment the Query API contains mostly read operations, with two exceptions: delete_all/2 and update_all/3, which support prepare_query/3.
At the same time, the Schema API contains delete/2 and update/2, which do not support prepare_query/3.
I suspect that the reason is that the Query API works on free-form queries composed with the Ecto DSL, where as the Schema API works on concrete structs that represent a DB row (that is, a schema). I can see the point that allowing applications to modify SQL that is intended to work on a predefined struct could be confusing. If the API promises that you’ll be inserting data for a struct, then if that SQL gets modified on the fly that promise is broken. This my just my guess: I couldn’t find it documented or explained anywhere.
And yet, I would argue that this is an inconsistency that we don’t need. Following the same line of reasoning, the Query API promises the developer that a certain query will be performed, but that query could be modified on the fly by the application using prepare_query/3. That’s also a promise being broken, and that’s fine. It’s a useful feature.
So, my questions are: is there is any reason why we can’t have an API to prepare queries for write operations? Can it be added?
First Post!
tompave
Hey there, I’m bumping this because I think it’s still relevant to something I’m working on.
Most Liked
Schultzer
I believe this can be solved by using the :autogenerate option for your field in your schema Ecto.Schema — Ecto v3.14.0.
And I think it derverse to be mentioned in the guide: Multi tenancy with foreign keys — Ecto v3.14.0
defmodule MyApp.Post do
use Ecto.Schema
schema "posts" do
field :title
field :org_id, :integer, autogenerate: {MyApp.Repo, :get_org_id, []}
has_many :comments, MyApp.Comment
timestamps()
end
end
Popular in Discussions
Other popular topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
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!"