DEV Community: Iván González Sáiz

Creating an AI-Powered Search Input With Phoenix LiveView

Iván González Sáiz — Mon, 24 Feb 2025 18:37:55 +0000

Building a Minimal Blog in Pure Elixir with Notion as a CMS

Iván González Sáiz — Mon, 17 Feb 2025 00:00:00 +0000

A proof of concept for a simple blog using pure Elixir, with Notion as a CMS and only three dependencies: Cowboy, HTTPoison, and Jason.

How to Change a Field Type in an Ecto Embedded Schema with a Migration

Iván González Sáiz — Fri, 14 Feb 2025 00:00:00 +0000

Changing a field type in an Ecto embedded schema requires both a code update and a database migration. This guide walks through the process, ensuring data consistency and avoiding common pitfalls.

Small Signals, Big Impact: How Tiny Acts of Self-Care Can Transform Workplace Well-Being

Iván González Sáiz — Thu, 13 Feb 2025 00:00:00 +0000

Small, thoughtful ways to support each other at work can have a big impact. Normalizing simple signals—like Slack statuses or images—helps create a healthier, more mindful workplace.

Do you know any good resource about mental health in the software industry?

Iván González Sáiz — Tue, 13 Nov 2018 10:18:25 +0000

Hi folks!

I would like to start here a discussion in which we can all together contribute to make an awesome list with all kind of resources (articles, talks, podcasts, organizations...) about mental health in the software industry.

One month ago I made a repository for this purpose. The initial idea was motivated by this tweet of Jess Lee on the World Mental Health Day: https://twitter.com/jessleenyc/status/1050107830794096641, so I guess it makes sense to share here the repository I made and so we can create something nice among the whole community 😊

This is the Github repository: https://github.com/dreamingechoes/awesome-mental-health. Do you know any good resource? I'll appreciate so much if you leave it in a comment here, or if you want you can make a pull request in the repository.

Thank you! 🤗 💖

Generate UUID fields in Phoenix with Postgresql

Iván González Sáiz — Fri, 10 Aug 2018 16:34:15 +0000

If for some reason you need to create a UUID field for your schema (a non-primary key field), and you don't want to manage the creation of the value to store on the new database record, you can specify in the migration to use as default value the uuid_generate_v4() Postgresql method, so it will be auto-generated on the insert:

defmodule App.Repo.Migrations.AddUuidFieldToUser do
  use Ecto.Migration

  def change do
    create table(:users) do
      add(:some_new_field, :uuid, default: fragment("uuid_generate_v4()"))
    end
  end
end

Depending on the configuration of your database, maybe you will see this error running the migration:

** (Postgrex.Error) ERROR 42883 (undefined_function): function uuid_generate_v4() does not exist

This is because your database hasn't the uuid-ossp module activated. You can activate by login to your database and execute this query:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

Or if you don't have access to the database, you can create a migration in order to execute the query like:

defmodule App.Repo.Migrations.AddUuidGenerateV4ExtensionToDatabase do
  use Ecto.Migration

  def change do
    execute("CREATE EXTENSION IF NOT EXISTS \"uuid-ossp\";")
  end
end

You can see more in-depth information about uuid-ossp module here. So when the migrations are executed properly, add to your schema the new field, and there you have it! Your new shiny auto-generated UUID field.

defmodule App.User do
  use Ecto.Schema

  import Ecto.Changeset

  schema "users" do
    ...

    field(:some_new_field, :binary_id)

    timestamps()
  end

  ...
end

This post is originally published here.

A dive into database multi-tenancy in Elixir with Ecto

Iván González Sáiz — Wed, 18 Jul 2018 09:13:38 +0000

Some time ago I had to tackle the migration of an application with a regular database to a multi-tenancy one, and I would like to share my experience here.

Despite the existence of libraries like apartmentex, triplex or tenantex, I wanted to make the migration as dependency free as possible, so I made my own management for the multi-tenancy.

Understanding Ecto prefix option

Most of the methods provided by Ecto which directly interacts with the database have a series of options, in which the most important one for multi-tenancy is prefix. According to the documentation, for Postgres users, prefix will specify the schema where the table is located, while for MySQL users will specify the database where the table is located. When no prefix is set, Postgres queries are assumed to be executed in the public schema, while MySQL queries are assumed to be executed in the database set in the config for the repo.

For example, if we want to insert a new element in our database with Repo.insert/2, we execute something like this:

case MyAppRepo.insert(%User{email: "user@example.com"}) do
  {:ok, struct}       -> # Inserted with success
  {:error, changeset} -> # Something went wrong
end

To do this in a multi-tenancy application, we need to specify the prefix option for the insertion, like this:

case MyAppRepo.insert(%User{email: "user@example.com"}, prefix: "some_tenant") do
  {:ok, struct}       -> # Inserted with success
  {:error, changeset} -> # Something went wrong
end

Main changes in our application

In order to prepare our application to work with a multi-tenant database, we have to make some changes in our code. Let's see the main changes with examples.

Default Phoenix scaffold

When we use the mix phx.gen.html task, a series of files are generated, among which is the context with all the functions to interact with the repo. For example, the function responsible for creating a new element will look like:

def create_user(attrs \\ %{}) do
  %User{}
  |> User.changeset(attrs)
  |> Repo.insert()
end

To enable multi-tenancy capabilities, we have to include in all the functions which interact with the repo (create, update, delete, list...) the tenant parameter to specify the prefix option:

def create_user(attrs \\ %{}, tenant) do
  %User{}
  |> User.changeset(attrs)
  |> Repo.insert(prefix: tenant)
end

Creating a new tenant

If we want to create a new tenant, we need to execute the proper query depending on the database we use (for Postgres will be CREATE SCHEMA). So we'll have a function like:

def create_schema(repo, tenant) do
  SQL.query(repo, "CREATE SCHEMA \"#{tenant}\"", [])
end

Listing available tenants

List all the available tenants will allow us to easily switch between them. To get this information, we have to make a query against the information_schema schema and select the schema_name field of the schemata table.

To be able to identify the schemas of my application, I like to use some prefix to differentiate my schemas from other ones (like tenant_), that's why I use the schema_prefix parameter on the query.

def list_tenants(repo, schema_prefix) do
  query =
    from(
      schemata in "schemata",
      select: schemata.schema_name,
      where: like(schemata.schema_name, ^"#{schema_prefix}%")
    )

  repo.all(query, prefix: "information_schema")
end

If you want to check if this function returns the correct information, you can enter the Postgres console and execute the following query:

database_dev=# SELECT schema_name FROM information_schema.schemata WHERE schema_name LIKE 'tenant_%';

Deleting a specific tenant

Like with the creation, if we want to delete a specific tenant, we need to execute the proper query depending on the database we use (for Postgres will be DROP SCHEMA). So we'll have a function like:

def drop_schema(repo, tenant) do
  SQL.query(repo, "DROP SCHEMA \"#{tenant}\" CASCADE", [])
end

Creating and running migrations on a specific tenant

The mix ecto.gen.migration task creates a new file with the migration we want into the priv/repo/migrations folder of the application. In case we need to be able to run migrations on the public schema and on the custom generated ones, we need to create a new priv/repo/tenant_migrations folder, and store the migrations which only will be run on the custom generated schemas on this folder.

We can create a custom task in order to generate and store new migrations directly on this folder. To avoid putting too much code in this post, here you have an example of the task so we can run something like this on the console:

user@computer:~$ mix app_name.gen.tenant_migration add_users_table

Once we have the new migration in our priv/repo/tenant_migrations folder, we can create as well a custom task to run the migrations for all the custom generated schemas. Again, to avoid putting too much code in this post, here you have an example of the task so we can run something like this on the console:

user@computer:~$ mix app_name.ecto.migrate_tenants

And finally, we can create a custom task to rollback the migrations for all the custom generated schemas. Here you have an example of the task so we can run something like this on the console:

user@computer:~$ mix app_name.ecto.rollback_tenants

At the end of the post I'll leave a link to an example Phoenix application with all the examples, so don't worry if I don't specify the code here.

Storing the current tenant in our application

We'll need to have the current tenant in which we have to execute all repo functions all along the application available. For this, which worked the best for me it's using Guardian to store the current tenant as a claim with sign_in. So, for example, if we have a controller to manage sessions, the create function will look like this:

def create(conn, %{
      "session" => %{
        "tenant" => tenant,
        "email" => email,
        "password" => password
      }
    }) do
  case Guardian.authenticate_user(email, password) do
    {:ok, user} ->
      conn
      |> Plug.sign_in(user, %{current_tenant: tenant})
      |> put_flash(:success, gettext("Welcome to AppName!"))
      |> redirect(to: page_path(conn, :index))

    {:error, message} ->
      conn
      |> put_flash(:error, message)
      |> redirect(to: session_path(conn, :new))
  end
end

Once the user logs in successfully, we'll be able to access that claim on the assigns of the conn, so, using the example seen before about the creation of a user, we can do something like:

Accounts.create_user(user_attrs, conn.assigns.current_tenant)

Things to take in mind

Once you have completed the migration of the code of our application, we have to take care of the dependencies used which directly interact with the repo. Most of the packages I saw do not allow the user to propagate the opts for the repo, so we'll can't use multi-tenancy in them, so be careful. And if you're going to create a new package, please allow the user to propagate the repo opts.

Example of a multi-tenancy application

I have developed a small application in Phoenix to be able to check the real behavior of all the concepts seen here. You can check the code in this repo.

This post is originally published here.