Hi,

I’m working on an Ecto Adapter for FoundationDB and one of my goals is to support migrations in the same manner that Ecto users are accustomed to (e.g. mix ecto.migrate). As I familiarized myself with the adapter behaviours, I learned that the Ecto.Adapter.Migration behaviour is a module in ecto_sql instead of the base ecto.

My first question: Is it reasonable or folly to continue developing a migration using ecto_sql as a depedency even though my database backend does not support SQL?

Of course I’m no stranger to folly, and I went ahead and tried it anyway, and got it mostly working. The rest of this post is related to the one blocker I had in getting it working seamlessly.

My desired implementation for Ecto.Adapter.Migration.lock_for_migrations/3 acquires a resource (a transaction reference from :erlfdb) that must then be telegraphed down to each execute_ddl. Ideally this could be directly supported by ecto_sql by allowing the behaviour to influence any future Repo operations within the execution of the migration.

Without this direct support from the library, a quick and dirty approach would be to store the reference in the Process dictionary, and then pick it back up later on in execute_ddl. However, this doesn’t work either because of the following Task creation:

Ecto.Migrator

    fn -> run_maybe_in_transaction(repo, dynamic_repo, module, fun_with_status, opts) end
    |> Task.async()
    |> Task.await(:infinity)

(The use of a Task here ensures that the rest of the migration steps have a fresh Process dictionary, preventing me from using it to keep track of data)

My second question: Why does ecto_sql use a Task in this manner?

Finally: Are there any other solutions that I’m missing without changing the underlying ecto_sql implementation? I’m reluctant to use global state such as an ets table unless it’s a last resort.

Thanks for your time!

Jesse