{"id":5315,"date":"2016-04-20T08:54:12","date_gmt":"2016-04-20T11:54:12","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=5315"},"modified":"2016-04-19T19:44:49","modified_gmt":"2016-04-19T22:44:49","slug":"ecto-2-0-0-rc-is-out","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2016\/04\/ecto-2-0-0-rc-is-out\/","title":{"rendered":"Ecto 2.0.0-rc is out!"},"content":{"rendered":"
We are really glad to announce the release candidate for Ecto 2.0 has been released. The upcoming Ecto version packs many goodies:<\/p>\n
The effective deprecation of Support for Introduction of a new SQL sandbox that allows developers to run tests that rely on the database concurrently;<\/p>\n<\/li>\n Support for subqueries, composite primary keys, There are many more features, bug fixes, and improvements. There are also backwards incompatible changes (hence the 2.0 version). We recommend you to check the CHANGELOG for more information<\/a>.<\/p>\n We recommend developers to give the release candidate a try. There are only a couple of improvements left before the final release<\/a>. In case you encounter an unexpected behaviour, please open up an issue report<\/a>.<\/p>\n This release supports both MySQL (mariaex) and PostgreSQL (postgrex) adapters.<\/p>\n This release candidate introduced some backwards incompatible changes for those using Ecto in their Phoenix projects. We summarize those changes below:<\/p>\n And now add the following entry to Phoenix projects by default use transactions in the test environment. Ecto 2.0 replaces the test transactions API by the new SQL sandbox. In your by<\/p>\n Then, in each by<\/p>\n That’s it! You can check the pull request that migrates Phoenix generators to Ecto 2.0-rc<\/a> for a detailed list of changes.<\/p>\n Before we move on, let’s explore exactly what the sandbox changes mean in the next section.<\/p>\n In previous versions, Ecto would keep a single connection to the database during tests and wrap the connection inside a transaction for every test. Ecto 2.0 introduces a sandbox mechanism where every test gets its own connection to the database, all of them wrapped in a transaction. Such allows tests to run concurrently by passing Let’s further explore the changes we did above. In your test helper, you should now see:<\/p>\n This command sets the sandbox to manual mode, meaning any Elixir process must explicitly check a database connection out before performing any database operation. If you open up The second line in the snippet above does exactly that: it checks a connection out and wraps it inside a transaction. After the connection is checked out, it belongs exclusively to the current test process.<\/p>\n If you enabled If the test is not asynchronous ( The SQL Sandbox provides other options for managing your concurrent tests and you can learn more about them in the Ecto documentation<\/a>.<\/p>\n We recommend developers to enable their concurrent tests and enjoy even faster test suites. When doing so, have the following in mind:<\/p>\n When testing your models, controllers, and views, most of the tests should be able to run concurrently as is, except if they are interacting with other Elixir processes in your application (see example in the next bullet);<\/p>\n<\/li>\n On the other hand, your channel tests require the collaboration between two processes: the test process and the channel process itself. If the channel process is accessing the database, you will need to allow explicitly it to use a database connection. See the Finally, tools for writing acceptance tests like Hound<\/a> and Wallaby<\/a> also support concurrent tests. You can find more information about doing so in the Phoenix.Ecto README<\/a>.<\/p>\n<\/li>\n<\/ul>\n We are really excited about Ecto 2.0. By focusing on Ecto as a tool instead of an abstraction layer, we expect developers to have a simpler and a more light-weight mechanism for interacting with databases.<\/p>\n In the upcoming weeks, we will publish a series of blog posts that focuses on the new features and perspectives brought by Ecto 2.0. Meanwhile, don’t forget to read the CHANGELOG<\/a> for the full list of changes.<\/p>\n We are really glad to announce the release candidate for Ecto 2.0 has been released. The upcoming Ecto version packs many goodies: We have migrated to DBConnection, which considerably improves the performance of how Ecto manages connections to the database as a whole. Improved pool management, faster encoding\/decoding, support for prepared queries and more; The … \u00bb<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[238,143,245],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/5315"}],"collection":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=5315"}],"version-history":[{"count":7,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/5315\/revisions"}],"predecessor-version":[{"id":5319,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/5315\/revisions\/5319"}],"wp:attachment":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=5315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=5315"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=5315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Ecto.Model<\/code> in favor of a more data-oriented approach. With Ecto 2.0, we want developers to focus on using Ecto as a tool instead of being responsible for your domain design;<\/p>\n<\/li>\n
many_to_many<\/code> associations and a more flexible approach to associations in general, including parallel preloading of associations;<\/p>\n<\/li>\n
insert_all<\/code> (alongside
update_all<\/code> and
delete_all<\/code>) and more.<\/p>\n<\/li>\n<\/ul>\n
Using Ecto 2.0.0-rc with Phoenix<\/h2>\n
\n
Phoenix.Ecto<\/code> dependency to
3.0.0-rc<\/code> (which depends on
ecto<\/code>
2.0.0-rc<\/code>) in your
mix.exs<\/code>:\n
{:phoenix_ecto, \"~> 3.0.0-rc\"}\n<\/code><\/pre>\n<\/li>\n
:ecto_repos<\/code> configuration for running tasks like
ecto.migrate<\/code> and others. Open up your
config\/config.exs<\/code> and add:\n
config :my_app, ecto_repos: [MyApp.Repo]\n<\/code><\/pre>\n<\/li>\n
test\/test_helper.exs<\/code>:\n
Mix.Task.run \"ecto.create\", ~w(-r <%= application_module %>.Repo --quiet)\nMix.Task.run \"ecto.migrate\", ~w(-r <%= application_module %>.Repo --quiet)\n<\/code><\/pre>\n
defp aliases<\/code> in your
mix.exs<\/code> file:<\/p>\n
\"test\": [\"ecto.create --quiet\", \"ecto.migrate\", \"test\"]\n<\/code><\/pre>\n<\/li>\n
errors.po<\/code> files<\/a> as well as your
error_helper.ex<\/code> view<\/a><\/p>\n<\/li>\n
test\/test_helper.exs<\/code>, replace the following:<\/p>\n
Ecto.Adapters.SQL.begin_test_transaction(MyApp.Repo)\n<\/code><\/pre>\n
Ecto.Adapters.SQL.Sandbox.mode(MyApp.Repo, :manual)\n<\/code><\/pre>\n
test\/support\/*_case.ex<\/code> file, replace:<\/p>\n
unless tags[:async] do\n Ecto.Adapters.SQL.restart_test_transaction(MyApp.Repo, [])\nend\n<\/code><\/pre>\n
:ok = Ecto.Adapters.SQL.Sandbox.checkout(MyApp.Repo)\n\nunless tags[:async] do\n Ecto.Adapters.SQL.Sandbox.mode(MyApp.Repo, {:shared, self()})\nend\n<\/code><\/pre>\n<\/li>\n<\/ol>\n
Concurrent transactional tests<\/h2>\n
async: true<\/code> to
use MyApp.ConnCase<\/code> (and similar) even if they rely on the database.<\/p>\n
Ecto.Adapters.SQL.Sandbox.mode(MyApp.Repo, :manual)\n<\/code><\/pre>\n
test\/support\/conn_case.ex<\/code>, you should see:<\/p>\n
setup tags do\n :ok = Ecto.Adapters.SQL.Sandbox.checkout(MyApp.Repo)\n\n unless tags[:async] do\n Ecto.Adapters.SQL.Sandbox.mode(MyApp.Repo, {:shared, self()})\n end\n\n :ok\nend\n<\/code><\/pre>\n
async: true<\/code> in your test case, its tests will run concurrently with tests from other test cases, each of them using its own and isolated database connection.<\/p>\n
:async<\/code> was not set to true), we will execute the
unless<\/code> block in
setup<\/code> and share the connection we just checked out with all other processes, effectively falling back to the mechanism we had in Ecto 1.0.<\/p>\n
\n
Ecto.Adapters.SQL.Sandbox.allow\/2<\/code> function<\/a>;<\/p>\n<\/li>\n
Summing up<\/h2>\n
\n
\n<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"