lindem
Hey fellow alchemists,
I was delighted to see that an sqlite3 adapter has indeed been developed since I tried phoenix and ecto last, so I decided to give it another try.
Sadly, with a phoenix liveview application, using the phx.gen.live generator, some generated tests always fail – specifically, the liveview tests deleting and updating items in a list always fail.
I tracked down the issue to the documented problem with the Ecto sandbox here.
I wish to just use the normal application repo with :memory: databases which can be destroyed and spun up relatively fast. I already found information regarding after_connect. I do not care enough about performance for this.
How do I define a new TestCase (like ConnCase) without the sandbox? The goal is to make the failing tests succeed and exclude them 
(If there was another way to make the generated tests run with sqlite3 with the sandbox enabled, I would be happy to be told how.)
The following creates a test project exhibiting the problem.
mix phx.new --database sqlite3 --live throwaway
cd throwaway
# create some entity in the db with associates liveviews
mix phx.gen.live Things Thing thing thingvalue:integer thingdescription:string
# copy routes into router.ex
mix test
Thanks for reading!
Because PostgreSQL always seems to be commented on: sqlite3 is going to be the production database, not some development crutch. I have been working with sqlite3 for almost 15 years, I am comfortable with it in this case. I know PostgreSQL well (and I love it too), but I do not wish to install, backup, and maintain another database cluster.
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
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
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
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, 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.
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 49 to 40- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
christhekeele
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:
Find an industry with such a spreadsheet-driven workflow, and:
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.
lindem
Consider yourself lucky then; I can assure you that they exist. Usually it is some B2B thing which requires employees from one firm to enter a bunch of information — of course, manually — into a system.
Then, the application runs a few weeks, then you get some calls, oh no, the people have found a way to enter data that is wrong, how could this be, so you tell them to edit the things which went wrong — of course, manually — via the form again.
Then, the application runs another few weeks, then you get a call from upper management, the department of redundancy department has claimed that data is missing yes the application was not designed for this, but yes, you have to add it please please please; so you rework the form, add new fields, and tell them they can now fix it — of course, manually — via the new and shiny form again, thankfully only entering the missing new field data, not the whole thing again.
User-facing things like webshops, dashboards, or the like, well these do not need CRUD forms as often.
And if you are wondering who wants to do all of this entering data into forms — of course, manually — well let me tell you: they hire interns who do it for them. Of course they have excel sheets that you could parse way faster, but oh noes, we cannot trust the IT department with our data that we are going to enter into the application the IT department manages for us.
Alright I am rambling. Sorry.
D4no0
Agree, moreover I find kind of strange the crud applications and forms everybody talks about, I had to do maybe 1 or 2 of them in my entire career, maybe I am doing something wrong?
christhekeele
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.
sodapopcan
If anyone told me they liked making forms, I would call them a liar to their face
Though then I would apologize because that was really uncalled for of me.
lindem
Well as I personally abhor creating CRUD forms, I will probably explore that route sometime in the future, if I can be bothered. I mean look at the typical forms: They are so boring to do and so similar to each other that there are programs making them (the generators)
— kind of like Eclipse emitting gobs of Java code for getters and setters back in the early 2000s.
I am sure there are people who love to make them, but to me, these forms are plain boring to do, so a generator sounds nice in theory. Also, when I look at the code I have just gotten (after generating new forms), they really do not look all that bad.
I have loved Django back in the day because of the Django admin: you could spin up a new project and show the customer forms for data entry practically on the spot. I think generators are not that far off in that regard, even if you need to generate authentication first.
Maybe I am not understanding them well enough, and maybe there are pain points involved I will still uncover — but that is part of the fun, I guess.
Thanks for all the input, I appreciate it
arcanemachine
Speaking personally (and I’m not an Elixir wizard like some of the others in this thread), I appreciate the generators as a reference point and teaching tool, but they obviously can’t be everything to everybody, and I only used them to figure out how the process works, and then wired up my own code afterwards. Their overall style doesn’t really do it for me, although I’m glad they exist since Phoenix changes fast and the community is small so there’s not a lot of newer material out there, compared to more popular frameworks.
You can customize the Phoenix generators which I think would work for me, but I haven’t gone down that road yet.
pdgonzalez872
There is value in at least seeing what the latest generators do. There are a lot of good practices that they nudge you towards. That’s the beauty of it → commit your work, run the generator, look at the changes suggested and take what you want/need while disposing of what you don’t want/need. My favorite (can’t express how much this is excellent) generator nudge is 1. Intro to Contexts — Phoenix v1.8.8, which makes you consider design right up front.
warmwaffles
Oh that’s good to know. I’ll take a look.
LostKobrakai
Phoenix 1.7 improved the generators a lot, so it’s easier to adapt them to custom markup. But at some point I think many usecase outgrow what the generators could deliver (without customizing the generators templates).