It covers what is special about Ecto, and why it is the way it is. If you check out just one resource from this list, watch this talk. Here is a load of awesome beginner- and intermediate-level materials that you can check out to learn more about the toolkit. Each of the items I talked about are covered better in different places I only tried to bring all the knowledge in one place for your convenience.
I’ve given a quick introduction, but there’s a lot still to explore out there. If you would like to read more about validations and constraints, this article is very nice. There are a lot of ready-made validations present, but you can also write your own custom validation functions and call them with validate_change. Iex(18)> changeset = _required(changeset, ) Now, we can play around with the database.įirst off, some alias preparations: iex(1)> alias Blog.Repo Schema-less queries, pure SQL instead of Ecto.Query, just using changesets for data validation – you want it, you can do it. While Ecto is frequently called a framework, it consists of a few modules, most of which you can use or not use, depending on your preferences. But you can technically use it to connect to whichever data source your heart prefers like MongoDB or ETS, among other things. For example, by default, Ecto is made to connect to SQL databases like MySQL & PostgreSQL. While it can cause some headaches in the start, it prevents you from making mistakes that you will forever remember when your project goes viral on Product Hunt.Ĭonfigurable. For example, if you don’t preload associated items, the framework will not fetch them for you. Ecto is explicit about what is happening: there is not so much behind-the-scenes magic as in other libraries. Generally, Ecto offers the same benefits as other things in the Elixir ecosystem: we focus on modularity and explicitness and of course it has macros.Įxplicit. If you are using Phoenix and Elixir, the chance is you will use Ecto. Would appreciate to get any advices, thanks.Most likely, the choice of using Ecto will come as a consequence of other choices that you’ve made. Can’t get motivation to preload entity when it could go only with id from API client.
= performer, attrs) doĪt this moment I stand on creating user with populating ids manually, because forms from frontend would send everything with populated ids. Performer: defmodule doĪlias MyApp.Production. |> validate_format(:email, unique_constraint(:phone) Import ~w(first_name last_name phone ~w(middle_name)a Migrations: create table(:users) doĪdd :user_id, references(:users, on_delete: :delete_all), null: falseĪdd :country_id, references(:countries), null: falseĪdd :native_language_id, references(:languages), null: falseĪdd :gender_id, references(:genders), null: falseĪdd :status_id, references(:performer_statuses), null: falseĬreate unique_index(:performers, ) Performer required to have user, country, native language and some other references. All of them belongs to User, because Manager can be Performer too. I have Manager, Performer and Client entities. I’m building GraphQL API with Phoenix + Absinthe (still didn’t touch) for my translation company’s CRM. I saw this post on medium about using only id's without assocs, but can’t see this approach confirmed as good in docs or threads. After books (Programming Elixir |> 1.6 and Programming Phoenix |> 1.4) and docs I read through so many posts and threads about using cast_assoc/3 and put_assoc/4 but still have issues with it usage and fully understand. I’m quite new to Elixir and Phonex but I felt in love with it so much.
0 kommentar(er)
