LionelMarco
Phoenix how to disabled Ecto sanbox in test- Test without sandbox
In previous Phoenix version I have been running test in my database without any sandbox and everyting run well.
Because already we have a specific database for development,configured in: config/test.exs
Now upgrade Phoenix and a new feature appear Sandbox
So I want to make all changes insert, update, delete, persistent.
I read this post but it is not was usefull for me:
I don’t want to use Shared mode:
I just only want to remove the sanbox an work in the database
Please can somebody tell me wich is the right way.
This is a part from my test.exs:
import Config
config :gis, Gis.Repo,
username: "gisuser",
password: "gisuser",
hostname: "localhost",
database: "gisapp" , #{System.get_env("MIX_TEST_PARTITION")}",
pool: Ecto.Adapters.SQL.Sandbox,
pool_size: 10
How to configure pool argument to use NO sandbox ?
What must to write to directly use my Repo
Or may be need to change : connn_case.ex file
I try removing the next line from test_helpers.exs
# Ecto.Adapters.SQL.Sandbox.mode(Gis.Repo, :manual)
and remove:
#pool: Ecto.Adapters.SQL.Sandbox,
from config/test.exs
But nothing happen
Also the documentation does not say anything of how to disable it.
please can anybody tell me how to proceed ?
Greetings
Marked As Solved
dimitarvp
I am probably not understanding you well here but what exactly is stopping you from having several DB dumps that you can restore on top of each other? And then when you want to test a certain scenario that needs database dump 1, 4 and 6, you just make a mix task alias to clear up the test DB and then load those dumps in order?
I’ve done that too, several times in my career. There’s really no point in running expensive seeding scripts if the required test data barely changes; so just make one functional and good copy of the DB and pg_dump it and then pg_restore it before tests.
Also Liked
dimitarvp
Are you really really sure you want that? You can just as well just seed / populate your test DB to have baseline data that you need – that’s a legitimate need, a good amount of applications cannot run adequate tests on an empty DB – and then proceed to run tests in the normal sandboxed manner.
nathanl
The way the sandbox works is:
- start a database transaction at the start of the test
- data gets inserted and updated in the database and read from the database within that transaction during the test
- at the end of the test, roll back the transaction instead of committing it
Since transaction COMMIT never happens, the data is never really persisted in the database. So I don’t think pg_dump would have any access to it.
dli
Late to the party, but you can do Ecto.Adapters.SQL.Sandbox.start_owner!(Repo, sandbox: false) in your DataCase setup. This prevents wrapping each test in a transaction that is rolled back at the end of the test.
Some options like sandbox are passed to Ecto.Adapters.SQL.Sandbox.checkout/2. The behaviour is documented there.
Popular in Questions
Other popular topics
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
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









