La bibliothèque Ecto

Elixir est un langage de programmation moderne, dynamique et fonctionnel utilisé pour créer des applications hautement distribuées et tolérantes aux pannes. ECTO est sa principale bibliothèque pour travailler avec des bases de données, nous fournissant des outils pour interagir avec les bases de données sous une API commune, version de la base de données parallèlement à notre application et gérer le traitement des données au sein de notre application.

Cet article examine rapidement les principaux aspects de la bibliothèque Ecto. Bien qu'il soit écrit pour Ecto 1.x, les exemples de cet article sont compatibles avec Ecto 2, et où se trouvent les écarts, ils sont mentionnés. Les connaissances de base de l'élixir et du mélange sont supposées.

Les plats clés

• ecto est une bibliothèque robuste dans Elixir pour gérer les opérations de base de données, fournissant une API commune pour l'interaction de la base de données, le versioning et le traitement des données.
• Le processus de configuration consiste à créer une nouvelle application de mix, à configurer les dépendances et à intégrer un module de référentiel Ecto dans l'arborescence de supervision de l'application pour une gestion efficace de la base de données.
• La fonction de migrations d'Ecto permet de verser la base de données à côté du code d'application, facilitant le suivi des modifications et l'application de différents états de base de données.
• Les schémas ECTO et les ensembles de change sont cruciaux pour définir les structures de données et gérer la validation des données, garantissant que seules les données valides sont manipulées et stockées.
• L'article démontre la création d'une application CRUD simple à l'aide d'Ecto, illustrant comment effectuer des opérations de base de données telles que la création, la lecture, la mise à jour et la suppression des enregistrements.

l'application

Nous allons construire une application très simple à partir de zéro qui stockera et récupérera des notes pour nous. Ce faisant, nous examinerons chacun des quatre composants principaux d'Ecto: des reposs, des schémas, des changements et des requêtes.

Création d'une nouvelle application

Commençons par générer une nouvelle application de mix:

mix new notex <span>--sup
</span>

L'indicateur --UP génère un code de passe-partout supplémentaire requis pour une application OTP. Cette application doit avoir un arbre de supervision, car Ecto en a besoin (plus à ce sujet en une minute).

Configuration des dépendances

Maintenant, mettons à jour notre fichier mix.exs avec certaines dépendances d'application. Pour cela, nous allons vouloir spécifier Ecto et l'un de ses adaptateurs. J'ai choisi d'utiliser MySQL pour cela, nous devons donc spécifier la bibliothèque Mariaex (Ecto prend en charge un certain nombre de bases de données).

Mettez à jour la fonction Application / 0 dans le fichier mix.exs avec les suivantes:

<span>def <span>application</span> do
</span>  <span>[applications: [:logger, :ecto, :mariaex],
</span>   <span>mod: {Notex, []}]
</span><span>end
</span>

et mettez à jour les DEP / 0 avec les suivants:

defp deps <span>do
</span>  <span>[{:ecto, <span>"~> 1.1.5"</span>}, # or "~> 2.0" for Ecto 2
</span>   <span>{:mariaex, <span>"~> 0.6.0"</span>}] # or "~> 0.7.0" for Ecto 2
</span><span>end
</span>

Remplissez maintenant les dépendances avec Mix Deps.get.

Ensuite, nous devons intégrer ces dépendances dans notre application. Cela impliquera de créer un nouveau module de wrapper pour un référentiel Ecto, de mettre à jour l'arborescence de supervision de notre application pour démarrer et superviser ce nouveau module et configurer les informations de connexion de l'adaptateur.

Commençons d'abord par définir un module Nothex.Repo sur lib / notex / repo.ex avec le code suivant:

mix new notex <span>--sup
</span>

L'emplacement de ce module (lib / app_name / repo.ex) est conventionnel. Chaque fois que nous utilisons une commande mix ecto, il recherchera par défaut le référentiel défini sur appname.repo. Nous pouvons le placer ailleurs, mais ce sera à la gêne de devoir spécifier son emplacement en utilisant le drapeau -r (ou --repo).

Le module Nothex.repo ci-dessus nous permet de travailler avec des bases de données à l'aide de l'ECTO. Il le fait en injectant tout d'abord les fonctions du module Repo d'ECTO (qui fournit l'API de requête de la base de données) et en nommant deuxièmement notre application OTP comme: NotEx.

Un référentiel Ecto nous fournit une interface commune pour interagir avec une base de données sous-jacente (qui est décidée par l'adaptateur utilisé). En tant que tel, tandis que Ecto utilise le repo de terminologie, il ne suit pas le modèle de conception du référentiel, car il s'agit d'un wrapper autour d'une base de données, pas d'une table.

Maintenant que nous avons défini le module Nothex.Repo, nous devons maintenant l'ajouter à notre arborescence de supervision dans le module NOTEX (sur lib / notex.ex). Mettez à jour la fonction START / 2 avec ce qui suit:

<span>def <span>application</span> do
</span>  <span>[applications: [:logger, :ecto, :mariaex],
</span>   <span>mod: {Notex, []}]
</span><span>end
</span>

Nous avons ajouté le module NotEx.Repo en tant que superviseur enfant (car il est lui-même une application OTP supervisée). Cela signifie qu'il sera supervisé par notre application OTP, et notre application sera chargée de le démarrer lors du démarrage de l'application.

Chaque connexion créée avec Ecto utilise un processus distinct (où le processus est tiré d'un pool de processus à l'aide d'une bibliothèque appelée Poolboy). Ceci est fait pour que nos requêtes puissent exécuter simultanément, tout en étant résilientes à partir de défaillances (par exemple, des délais d'attente). Notre application nécessite donc OTP, car Ecto a ses propres processus qui doivent être supervisés (y compris un arborescence de supervision supervisant un pool de connexions de base de données). Cela peut être vu en utilisant la bibliothèque d'observateurs d'Erlang, qui nous permet de visualiser les processus d'une application.

Après avoir ajouté le référentiel à nos processus de travail à superviser, nous devons enfin configurer l'adaptateur afin qu'il puisse communiquer avec notre base de données. Placez le code suivant à la fin du fichier `config / config.exs` (mise à jour des détails si nécessaire):

mix new notex <span>--sup
</span>

Ici, nous spécifions le nom de notre application OTP (: NOTEX) et le nom de notre module fraîchement défini (Nothex.repo) pour activer la communication avec la base de données. Les autres options de configuration doivent être assez explicites. Ecto 2 nous oblige à spécifier en outre une liste des reposs ecto que nous utilisons dans notre application.

ecto nous fournit en fait un raccourci pour configurer le module de réapprovisionnement ci-dessus en tant que tâche de mixage: mixer ecto.gen.repo. Cela génère le module de référentiel pour nous et met à jour le fichier config.exs avec une configuration de base (le module Repo doit encore être ajouté manuellement à l'arborescence de supervision). J'ai évité de l'utiliser ici principalement pour des raisons didactiques de montrer comment configurer l'ecto manuellement (cela, et le fait que le générateur de repo suppose que vous utilisez Postgres, nous aurions donc dû mettre à jour l'adaptateur dans la configuration de toute façon).

Avant de continuer, jetons un coup d'œil très rapide à la hiérarchie des processus. (Notez que si vous exécutez Ecto 2, vous devrez d'abord créer la base de données avec Mix Ecto.Create avant de tenter de compiler le projet.) Démarrez notre application dans le shell interactif d'Elixir, puis démarrez l'observateur:

<span>def <span>application</span> do
</span>  <span>[applications: [:logger, :ecto, :mariaex],
</span>   <span>mod: {Notex, []}]
</span><span>end
</span>

Navigant vers l'onglet Application, nous pouvons voir les processus de l'application, y compris ceux qui sont les superviseurs:

C'est pourquoi cette application doit être une application OTP. Mais c'est aussi loin dans le terrier du lapin que nous irons en ce qui concerne les processus et le OTP dans cet article. Ils seront couverts plus en détail dans les articles ultérieurs à venir.

Création de la base de données et des tables

Maintenant, avec cette configuration, nous pouvons créer notre base de données et nos tables. Pour créer la base de données, exécutez la commande suivante:

defp deps <span>do
</span>  <span>[{:ecto, <span>"~> 1.1.5"</span>}, # or "~> 2.0" for Ecto 2
</span>   <span>{:mariaex, <span>"~> 0.6.0"</span>}] # or "~> 0.7.0" for Ecto 2
</span><span>end
</span>

Pour créer les tables, nous utiliserons la fonction de migrations d'Ecto. Les migrations nous permettent de verser la base de données à côté du code source, permettant de suivre les modifications et de différents états. Nous créons donc de nouvelles migrations chaque fois que nous souhaitons modifier la structure de la base de données.

Une nouvelle migration peut être créée avec la commande mix ecto.gen.Migration comme suit:

defmodule Notex<span>.Repo do
</span>  use Ecto<span>.Repo, otp_app: :notex
</span><span>end
</span>

Ce qui précède devrait créer un nouveau dossier de migrations à PRIV / Repo / Migrations, ainsi qu'un nouveau fichier de migration. Ce fichier est préfixé avec la date et l'heure créées (pour une commande de répertoire facile), ainsi que notre nom de migration. Ouvrez ce fichier et modifiez-le à ce qui suit:

mix new notex <span>--sup
</span>

Garder les choses simples, nous avons utilisé la macro de création pour définir une nouvelle table (appelée notes) avec deux champs: note_name et note_content. La clé principale est automatiquement créée pour nous (ID nommé). Alors que nos deux champs ont été définis comme des cordes simples, Ecto prend en charge de nombreux types - que vous pouvez consulter dans sa documentation.

Avec notre migration terminée, nous pouvons maintenant exécuter la migration avec la commande suivante:

<span>def <span>application</span> do
</span>  <span>[applications: [:logger, :ecto, :mariaex],
</span>   <span>mod: {Notex, []}]
</span><span>end
</span>

Cela créera notre table de notes avec 3 champs (le troisième champ étant l'ID, la clé principale).

Avec le tableau créé, il est maintenant temps de créer un modèle pour la table. Le modèle est utilisé pour définir les champs de la table et leurs types respectifs. Ceux-ci seront utilisés par l'application et le DSL de l'interrogation d'ECTO lors de la diffusion et de la validation des données. Les définitions du modèle peuvent également contenir des champs virtuels (contrairement aux définitions de migration), qui sont utilisés pour contenir des données éphémères généralement que nous ne voulons pas persister (comme les mots de passe non lâchés).

Dans sa forme la plus élémentaire, notre modèle NOTEX.NOTE (situé chez Lib / Nothex / Note.ex) ressemblera à ce qui suit:

defp deps <span>do
</span>  <span>[{:ecto, <span>"~> 1.1.5"</span>}, # or "~> 2.0" for Ecto 2
</span>   <span>{:mariaex, <span>"~> 0.6.0"</span>}] # or "~> 0.7.0" for Ecto 2
</span><span>end
</span>

Nous injectons le module Ecto.Schema afin que nous puissions utiliser la macro de schéma pour définir les champs et leurs types. Ces définitions deviendront importantes plus tard lorsque nous aurons utilisé des changements d'Ecto. Quelque chose d'autre que la macro de schéma fait pour nous est de définir une structure du type comme le module actuel (dans ce cas, il est% notEx.note {}). Cette structure nous permettra de créer de nouveaux ensembles de changes (plus à ce sujet bientôt) et d'insérer des données dans le tableau.

Avec juste ce qui précède, nous pouvons tirer IEX et commencer à interroger notre base de données:

defmodule Notex<span>.Repo do
</span>  use Ecto<span>.Repo, otp_app: :notex
</span><span>end
</span>

(Informations de débogage de la console évoluées.)

Le module de requête de

ecto est importé pour rendre toutes les macros DSL de requête (comme de) à notre disposition dans la coque. Nous créons ensuite une requête simple pour retourner tous les enregistrements (en utilisant tout / 1), en sélectionnant uniquement le champ Note_name. Cela revient une liste vide, car nous n'avons actuellement aucun enregistrement dans la base de données. Créons un nouvel ensemble de modifications et insérons-le dans le tableau:

<span>def <span>start</span>(_type, _args) do
</span>  import Supervisor<span>.Spec, warn: false
</span>
  children <span>= [
</span>    supervisor<span>(Notex.Repo, []),
</span>  <span>]
</span>
  opts <span>= [strategy: :one_for_one, name: Notex.Supervisor]
</span>  Supervisor<span>.start_link(children, opts)
</span><span>end
</span>

(Informations de débogage de la console évoluées.)

Nous commençons par importer à nouveau ecto.Query, qui est nécessaire pour la dernière opération de récupération (en particulier pour la macro de From). Nous utilisons ensuite la fonction modifie / 1 de ecto.changeset pour créer un nouvel ensemble de modifications à l'aide d'un% notEx.note {} struct. Cet ensemble de change est ensuite inséré, puis récupéré.

Les ensembles de modifications sont ce que nous utilisons lorsque nous travaillons avec des enregistrements. Ils nous permettent de suivre les modifications des données avant l'insertion, ainsi que de valider ces modifications et de lancer leurs valeurs aux types de données corrects (selon notre définition de schéma). Comme nous pouvons le voir sur ce qui précède, la structure �to.changeset {} contient un certain nombre de membres qui seront utiles pour voir si les modifications sont valides (changeset.valid?), Quelles sont les erreurs si elles ne l'ont pas . Errors), et ainsi de suite.

mettons à jour le modèle NOTEX.NOTE pour démontrer certains ensembles de modifications et les opérations de requête, car les effectuer dans IEX devient un peu désordonnée:

mix new notex <span>--sup
</span>

passons par chacune des cinq nouvelles fonctions. La fonction insert_note / 1 crée une nouvelle note pour nous. La fonction CAST / 4 gère la coulée des données des champs d'entrée à leurs types de champs respectifs (selon notre définition de schéma), ainsi que garantir que tous les champs requis ont des valeurs. Le SCHOCHET RETOURNÉ de Cast / 4 est ensuite inséré dans la base de données. Notez que dans ECTO 2, les fonctions Cast / 3 et Validate_Required / 3 doivent être utilisées à la place de Cast / 4.

La fonction get_notes / 0 renvoie une liste de tuples de toutes les notes dans le tableau. Cela se fait grâce à la correspondance de motifs dans l'instruction SELECT. (Nous aurions pu assez facilement renvoyer une liste de cartes à la place avec Select:% {id: n.id, note_name: n.note_name}, par exemple.)

La fonction get_note / 1 récupère une seule note de la table en fonction de l'ID de note. Cela se fait via le get! Fonction, qui renvoie la note lors du succès ou lance l'échec.

La fonction Update_Note / 1 met à jour une note en fonction de l'ID de note fourni. Remarquez la clé de chaîne dans la carte de la signature de la fonction (la touche ID). Il s'agit d'une convention que j'ai tirée dans le cadre Phoenix, où les données non artificielles (généralement fournies par l'utilisateur) sont représentées dans des cartes avec des touches de chaîne, et les données désinfectées sont représentées dans des cartes avec des touches d'atomes. Pour effectuer la mise à jour, nous récupérons d'abord la note en fonction de son ID dans la base de données, puis utilisons la fonction Cast / 4 pour appliquer les modifications à l'enregistrement avant de finalement insérer l'ensemble de modifications mises à jour dans la base de données.

La fonction delete_note / 1 supprime une note de la base de données. Nous récupérons d'abord la note de la base de données via son ID (similaire à la fonction Update_note / 1), puis le supprimais à l'aide de la note retournée Strust.

Avec les opérations CRUD ci-dessus en place, passons à l'IEX et essayons-le:

<span>def <span>application</span> do
</span>  <span>[applications: [:logger, :ecto, :mariaex],
</span>   <span>mod: {Notex, []}]
</span><span>end
</span>

(Informations de débogage de la console évoluées.)

Et là, nous l'avons, une application CRUD de base utilisant Ecto! Nous pourrions rendre la sortie et rendre l'API plus agréable contre lesquels vous interrogez, mais je vais laisser cela comme une extension, car celles-ci sont tangentielles à ce que nous couvrons (et cet article est assez long, je pense).

Conclusion

Cet article a examiné les principes fondamentaux de l'ECTO en créant une application CRUD simple à partir de zéro. Nous avons vu les nombreuses capacités Ecto Packs pour gérer les enregistrements et les changements de base de données, y compris les migrations, les schémas et son DSL de requête, ainsi que sur des sujets tangentiels tels que OTP. J'espère que cela a servi de bonne introduction à ceux qui cherchent à se mettre au courant pour travailler avec des bases de données dans Elixir!

Dans mon prochain article, je regarde les bases d'Ecto en interrogation Ecto d'Elixir.

Questions fréquemment posées (FAQ) sur la bibliothèque Ecto d'Elixir

Quel est le but de la bibliothèque Ecto d'Elixir?

La bibliothèque Ecto d'Elixir est un wrapper de base de données et une requête intégrée en langage pour Elixir. Il est conçu pour gérer toutes les tâches de manipulation des données dans une application, fournissant une API unifiée pour interagir avec les bases de données. Ecto vous permet de créer, lire, mettre à jour et supprimer des enregistrements, ainsi que d'effectuer des requêtes, des transactions et des migrations complexes. Il prend en charge différentes bases de données, notamment PostgreSQL et MySQL, ce qui en fait un outil polyvalent pour tout développeur Elixir.

Comment Ecto gère-t-il la validation des données?

ECTO utilise une fonctionnalité appelée "changements" pour la validation des données pour la validation des données . Un SCHOIGNET est une structure de données qui contient des modifications à apporter à la base de données, ainsi que des erreurs, des validations et des informations de coulée de type. Les ensembles de modifications garantissent que seules les données valides sont enregistrées dans la base de données, fournissant un mécanisme robuste pour la validation des données et la gestion des erreurs.

Comment puis-je effectuer des requêtes complexes avec Ecto?

Ecto fournit une puissante API de requête puissante Cela vous permet d'écrire des requêtes complexes d'une manière lisible et efficace. Vous pouvez utiliser le mot-clé depuis pour démarrer une requête et chaîner d'autres fonctions comme sélectionner, où, commander_by et rejoindre pour construire la requête. ECTO prend également en charge les sous-requêtes, les agrégations et autres caractéristiques SQL avancées.

Quel est le rôle d'Ecto.Schema dans la bibliothèque Ecto d'Elixir?

ecto.schema est un module qui définit la structure de votre votre données. Il mappe les données de votre application Elixir à vos tables de base de données et vice versa. Avec ecto.schema, vous pouvez définir les champs de vos données, leurs types et toutes les associations entre différents schémas.

Comment Ecto gère-t-il les migrations de la base de données?

Ecto fournit un mécanisme intégré Pour gérer les migrations de la base de données. Les migrations sont des scripts qui modifient la structure de votre base de données au fil du temps. Ils peuvent créer ou supprimer des tables, ajouter ou supprimer des colonnes, créer des index, etc. La fonction de migration d'ECTO garantit que ces modifications sont effectuées de manière contrôlée et réversible.

Ecto peut-il travailler avec les bases de données NOSQL?

Alors qu'Ecto a été principalement conçu pour les bases de données SQL, il peut également fonctionner avec Nosql Bases de données via l'utilisation des adaptateurs. Cependant, certaines fonctionnalités telles que les migrations et les requêtes complexes peuvent ne pas être entièrement prises en charge ou peuvent fonctionner différemment en fonction de la base de données et de l'adaptateur NOSQL spécifiques utilisés.

Comment Ecto gére-t-il les transactions?

Ecto fournit un simple et API puissante pour gérer les transactions. Vous pouvez utiliser la fonction ecto.repo.transaction pour démarrer une transaction, et toutes les modifications apportées dans la transaction seront engagées dans la base de données si la fonction renvoie: OK, ou en arrière si elle revient: erreur.

Qu'est-ce que ecto.multi?

ecto.multi est une caractéristique d'Ecto qui vous permet de regrouper plusieurs opérations ensemble. Il est utile lorsque vous devez effectuer plusieurs opérations dans une seule transaction, et vous voulez que tous réussissent ou échouent dans son ensemble. Ecto.multi garantit la cohérence des données et facilite la gestion des erreurs.

Comment puis-je utiliser Ecto avec Phoenix?

Phoenix, le framework Web populaire pour Elixir, s'intègre parfaitement à Ecto. Phoenix utilise l'ECTO pour tous ses besoins de manipulation de données et fournit des générateurs qui facilitent la création de schémas, de changements et de migrations Ecto. Vous pouvez également utiliser l'API de requête d'Ecto directement dans vos contrôleurs et vues Phoenix.

Comment puis-je en savoir plus sur Ecto?

La documentation officielle Ecto est une excellente ressource pour en savoir plus sur Ecto. Il fournit un guide complet de toutes les fonctionnalités de l'ECTO, ainsi que des exemples et des meilleures pratiques. Vous pouvez également trouver de nombreux tutoriels et articles de blog en ligne qui couvrent divers aspects de l'ECTO plus en détail.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!