We have spent the last 3 months working hard to release Ecto 3.0. As we get closer and closer to Ecto 3.0 release, we will do a series of blog posts highlighting what is up and coming.<\/p>\n
Despite the major version change, we have kept the number of user-facing breaking changes to a minimum, mostly around three areas:<\/p>\n
- \n
- Split the Ecto repository apart<\/li>\n
- Remove the previously deprecated Ecto datetime types in favor of the Calendar types that ship as part of Elixir<\/li>\n
- Update to the latest JSON handling best practices<\/li>\n<\/ul>\n
We will start our series of posts by going over the “bad news” and discuss how those breaking changes will affect you. In the next posts, we will highlight all of the upcoming new features and performance improvements.<\/p>\n
Let’s get started.<\/p>\n
Split Ecto into
ecto<\/code> andecto_sql<\/code><\/h2>\nEcto 3.0 will be broken in two repositories:
ecto<\/code> andecto_sql<\/code>. Since Ecto 2.0, an increased number of developers and teams have been using Ecto for data mapping and validation, without a need for a database. However, adding Ecto to your application would still bring a lot of the SQL baggage, such as adapters, sandboxes and migrations, which many considered to be a mixed message.<\/p>\nIn Ecto 3.0, we will move all of the SQL adapters to a separate repository and Ecto will focus on the four building blocks: schemas, changesets, queries and repos. You can see the discussion in the issues tracker<\/a>.<\/p>\n
If you are using Ecto with a SQL database, migrating to Ecto 3.0 will be very straight-forward. Instead of:<\/p>\n
{:ecto, \"~> 2.2\"}<\/code><\/p>\nYou should list:<\/p>\n
{:ecto_sql, \"~> 3.0\"}<\/code><\/p>\nAnd if you are using
Ecto<\/code> only for data manipulation but with no database access, then it is just a matter of bumping its version. That’s it!<\/p>\nCalendar types<\/h2>\n
Ecto.Date<\/code>,Ecto.Time<\/code> andEcto.DateTime<\/code> no longer exist. Instead, developers should useDate<\/code>,Time<\/code>,DateTime<\/code> andNaiveDateTime<\/code> that ship as part of Elixir and are the preferred types since Ecto 2.1. Odds are that you are already using the new types and not the deprecated ones.<\/p>\nWe have used this opportunity to unify the support for microseconds across all databases. The types
:time<\/code>,:naive_datetime<\/code>,:utc_datetime<\/code> will now discard any microseconds information. Ecto v3.0 introduces the types:time_usec<\/code>,:naive_datetime_usec<\/code> and:utc_datetime_usec<\/code> as an alternative for those interested in keeping microseconds. If you want to keep microseconds in your migrations and schemas, you will need to configure your repository:<\/p>\nconfig :my_app, MyApp.Repo,\n migration_timestamps: [type: :naive_datetime_usec]\n<\/code><\/pre>\nAnd then in your schema:<\/p>\n
@timestamps_opts [type: :naive_datetime_usec]<\/code><\/p>\nNote that database adapters have also been standardized to work with Elixir types and they no longer return tuples when developers perform raw queries.<\/p>\n
JSON handling<\/h2>\n
Ecto v3.0 moved the management of the JSON library to adapters. All adapters should default to
Jason<\/code><\/a>.<\/p>\nThe following configuration will emit a warning:<\/p>\n
config :ecto, :json_library, CustomJSONLib<\/code><\/p>\nAnd should be rewritten as:<\/p>\n
# For Postgres\nconfig :postgrex, :json_library, CustomJSONLib\n\n# For MySQL\nconfig :mariaex, :json_library, CustomJSONLib\n<\/code><\/pre>\nIf you want to rollback to Poison, you need to configure your adapter accordingly:<\/p>\n
# For Postgres\nconfig :postgrex, :json_library, Poison\n\n# For MySQL\nconfig :mariaex, :json_library, Poison\n<\/code><\/pre>\nWe recommend everyone to migrate to Jason. Built-in support for Poison will be removed in future Ecto 3.x releases.<\/p>\n
Other changes<\/h2>\n
Now that we have unified the data types, the
Ecto.DataType<\/code> protocol is no longer necessary and has been removed. If you were implementing it in the past, you can just completely remove it and everything should still just work.<\/p>\nWe have also improved
Ecto.Multi.run\/5<\/code> to receive the repo module in which the transaction is executing as the first argument. Therefore, if you are passing amodule-function-args<\/code> to any of theEcto.Multi<\/code> functions, they need to be adapted to receive the repo as the first argument. This change will most likely lead to cleaner and less coupled code.<\/p>\nFinally, one of the changes we will cover in future posts is how the “prefix” support (called “schemas” in PostgreSQL) has been drastically improved in Ecto 3.0. Previously, you could only set a prefix for the whole query but Ecto 3.0 will give developers granular control over those. Therefore, if you are setting the
@schema_prefix<\/code> attribute in a schema, you will have to remember it only affects that particular schema, and no longer the whole the query.<\/p>\nWe are really excited with Ecto 3.0! With the breaking changes out of the way, we are ready to explore many of the upcoming new features in the next blog posts.<\/p>\n
![\"banner-elixir](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/10\/Elixir_2-1-1024x213.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Welcome to the “A sneak peek at Ecto 3.0” series: Breaking changes (you are here!) Query improvements part 1 Query improvements part 2 Performance, migrations and more We have spent the last 3 months working hard to release Ecto 3.0. As we get closer and closer to Ecto 3.0 release, we will do a series … \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],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7803"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=7803"}],"version-history":[{"count":11,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7803\/revisions"}],"predecessor-version":[{"id":7882,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7803\/revisions\/7882"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=7803"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=7803"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=7803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}