Add MongoDB database option to Phoenix installer - #6710
Conversation
3eb4444 to
9930978
Compare
|
Does this work with the other generators, e.g. |
9930978 to
4a5c56a
Compare
4a5c56a to
8b817d8
Compare
|
It does, but it depends on that linked |
|
Hi! I wanted to share my experience using Mongo+Phoenix for a few years (at least ~2023-2026). In short, the experience trying to use it with Ecto was so frustrating to the point I decided it was not worth it. The existing libraries didn't seem to get much love or use at the time. Eventually, I went with using the driver https://github.com/zookzook/elixir-mongodb-driver, which was the most active driver fork at the time, without the Ecto abstraction (but using Ecto for changesets/forms). I see that things have since changed in I would expect to discover several caveats when using MongoDB with Ecto and the Phoenix generators, some of them were already spelled out in the AGENTS.md/ecto usage rules addition. |
rhcarvalho
left a comment
There was a problem hiding this comment.
Review Notes:
- This requires carving out several exceptions/conditional behavior in the templates. Not sure if we cover it all, including other
mix phx.gen.*tasks. - Missing integration tests
There was a problem hiding this comment.
We don't generate a docker-compose.yml file for any other choice of database.
I'd expect adding MongoDB wouldn't change that -- it's on the end user to decide how they organize their dev environment (e.g. local MongoDB, Docker container, or external server).
| - **Primary keys must be `:binary_id`** — configured automatically via `config :app, :generators, binary_id: true`. All `mix phx.gen.*` commands honour this automatically; no `--binary-id` flag needed. | ||
| - **No SQL joins** — use embedded schemas (`embeds_one`, `embeds_many`) for nested data, or separate queries for associations. | ||
| - **Migrations create collections and indexes**, not tables. `create table(:name)` → MongoDB collection. `add :col, :type` → no-op (schema-less). | ||
| - **Test isolation** uses `Mongo.Ecto.truncate(Repo)` before each test, not `Ecto.Adapters.SQL.Sandbox`. |
There was a problem hiding this comment.
José recently cleanup agents rules, and one of the updates was to simply improve the scaffolded test setup replacing an agent rule.
I think we could do the same here: scaffold the project with tests setup correctly, no need to instruct agents.
| case Repo.one(query) do | ||
| nil -> nil | ||
| token_record -> | ||
| <%= schema.singular %> = Repo.get(<%= inspect schema.alias %>, token_record.<%= schema.singular %>_id) |
There was a problem hiding this comment.
Oh, noticing this does 2 queries for getting a session token. Perhaps because of the "no joins" limitation?
Considering there is no transaction here, I think we need to understand the security implications of that data race before promoting it.
|
I also think we should close the gaps in Ecto compatibility rather than adding conditionals to Phoenix. For example, Mongo could accept references and document they have no effect and defauilt to binary_id |
|
I appreciate the effort to make using MongoDB with Phoenix easier, but realistically I don't see us merging this as it would require that we also maintain it. Maintaining the existing SQL adapters is not too much effort since they all work mostly the same and don't need specific code changes in generators etc. If it was as simple as changing the adapter, it would be a different discussion though. Even if we don't merge this, I think a good way forward could be to provide an Igniter-based installer that you then run on top of |
Hi! I'm opening this PR in coordination with elixir-mongo/mongodb_ecto#205 in
mongodb_ecto, that aims to make using MongoDB as seamless as its SQL counterparts.This PR adds the
--database mongodboption and the plumbing necessary so that it behaves like all of the other database options.