Or something right, if you enjoy working on them as much as you indicate

At the end of the day, though, a HUGE % of B2B companies fall into 1 of 2 buckets:

1. A domain-specific, context aware, edit-history-enabled pretty replacement for an Excel spreadsheet that powers an entire industry
2. A domain-specific, context aware, edit-history-enabled pretty replacement for a single python script + an Excel spreadsheet that powers an entire industry

Find an industry with such a spreadsheet-driven workflow, and:

• put the spreadsheets in a database
• access it with CRUD
• track modification history from form submissions
• use domain knowledge to empower better visualizations

and you have a successful startup! For more advanced usecases, encode the script in a background job framework and you’re good to go.

This is clearly a very common need, so I am grateful that Phoenix (+ Oban) cover these usecases thoroughly, in case I end up working on such a project again, though I do avoid them as well.

The only generator I use day to day is mix ecto.gen.migration everything else is build as I need it. None of the generators produce even close to what we have for our admin panel and structuring. That has been my experience with generators (rails, django, phoenix, etc…) for the last 8 years.

At the end of the day, generators are just a way of copying somebody else’s code into your project. That will always require that your code style/conventions/structure match theirs to work out of the box.

I would rather copy my own project’s code with its own existing style/conventions/structure, so I essentially only use generators very early on in a project, to get the latest dependencies/configuration/wiring from the excellent phoenix generators, since phoenix and especially liveview is still iterating fast (though we are due for a liveview 1.0 soon so I expect this to slow down dramatically).

By the time I have a roughly working initial project setup, I’ve modified these generated defaults and conventions to suit my needs enough that I can copy my own code as a “template”. I pretty much only use the ecto migration generator from there on out, mostly so that I don’t have to generate my own timestamps for migration names. (Even then I write most migrations in pure SQL, so completely replace the migration DSL inserted into those files.)

One reason I ditch the generators very early on is because I never actually want to use Phoenix’s namespacing/context conventions, so pretty much any initial codebase I write quickly strays from their conventions, you may get more milage if you follow them.

I do to, but two problems you will face doing this.

1. Right now exqlite is dependent on :db_connection which makes :memory: a bit difficult to work with. There is discussion to remove it as a dependency. Replace DirtyNIF execution model with a different mechanism · Issue #192 · elixir-sqlite/exqlite · GitHub
2. Every time you check out a new connection, you will need to run the migrations from start to finish OR load the database structure every time you check it out. Just something to keep in mind if you want to use the :memory: route.

I definitely have a dream of using :memory: for testing in a massively parallel way. The first step to accomplishing this is to remove the dependency on :db_connection and implement our own pooling mechanism or just live with one genserver. The second step is to make that spin up time be as fast as possible when using :memory: and benchmark that against using the sandbox.

If you want to use the generators you could always generate with a plural name then edit the migration and the schema to be singular.

…or open an issue in Phoenix to make singular table names work! Not sure it would be accepted but you can always try