We have one more SQLite 3 library!

Mentioning it as it’s code may give you some hints. Maybe even it’s author @warmwaffles would give @dmitriid some help.

I was pretending to help @warmwaffles as he did 100% of the work.

Ah, I’ve got nothing to hide.

Recently started a new job and it’s taking most of my time – initial good impressions, you know.

Also due to the closure of the gyms I got hit by very low energy levels and I am not motivated to work on anything beyond the main job.

Happily though both things will come to an end soon (not the job itself, just the initial flurry of tasks in it) and I expect to resume work on xqlite. Going to spend an hour on the treadmill in the gym at Monday or I’ll change my name!

Last status was that I completely reworked the Rust code and it’s at least 5x faster now, plus much cleaner. And for my library the Rust code is honestly 90% of the work.

What can you do to help? Well, once I have the Rust code in place (which I do, but have to do a few final iterations on it, add some more unit tests and optionally benchmarks) and push it in the GitHub repo, you can contribute test scenarios and the tests themselves. Also I’d appreciate a second pair of eyes on the Elixir API design. Promise to keep you in the loop since you expressed interest. Expect actual updates in the next 2-4 weeks.

AFAIK Ecto 3 locks tables and uses two connections to the db during migrations. Maybe you can use some combination of :migration_lock option and the number of connections pool_size: 1 to work around your problem.

I couldn’t make your example work since it’s missing a dependency:

Unchecked dependencies for environment dev:
* sqlitex (deps/sqlitex)
  the dependency is not available
** (Mix) Can't continue due to errors on dependencies

Hello

I am rather fond of Sqlite and thought it would be fun to update sqlite_ecto2 so it works with Ecto 3.

I have hit the same {"busy",0..5} issue as @dmitriid.

This appears to be due to the Ecto migrator running the migration in a transaction via an async task, but before the transaction commits the parent task tries to insert into the schema_migrations table. I believe this is the cause of the busy responses because the SQLite database is locked at the beginning of the transaction which prevents the insert to the schema_migrations table from the parent connection.

This home-baked debug output from running the tests shows the PIDs associated with the relevant queries and you can see #PID<0.425.0> starts a transaction but then the parent #PID<0.426.0> tries an insert before the original transaction commits.

{#PID<0.426.0>,
 "CREATE TABLE IF NOT EXISTS \"schema_migrations\" (\"version\" BIGINT PRIMARY KEY, \"inserted_at\" NAIVE_DATETIME)"}
{#PID<0.426.0>, "SELECT s0.\"version\" FROM \"schema_migrations\" AS s0"}
{#PID<0.426.0>, "SELECT s0.\"version\" FROM \"schema_migrations\" AS s0"}

{#PID<0.425.0>, "BEGIN"}
12:09:43.870 [info]  == Running 0 Ecto.Integration.Migration.change/0 forward
12:09:43.873 [info]  create table users
{#PID<0.425.0>,
 "CREATE TABLE \"users\" (\"id\" INTEGER PRIMARY KEY, \"name\" TEXT, \"custom_id\" UUID, \"inserted_at\" NAIVE_DATETIME NOT NULL, \"updated_at\" NAIVE_DATETIME NOT NULL)"}
12:09:43.875 [info]  == Migrated 0 in 0.0s

{#PID<0.426.0>,
 "INSERT INTO \"schema_migrations\" (\"version\",\"inserted_at\") VALUES (?1,?2)"}

{"busy",0}
{"busy",1}
{"busy",2}
{"busy",3}
{"busy",4}
{"busy",5}

This seems to be related to the following function in ecto_sql:

Can anybody point me in the right direction so I can solve this in the adapter? I had a play with implementing lock_for_migrations/3 but don’t think this is relevant as there isn’t, to my knowledge, an SQLite command that would modify the behaviour I’m seeing.

I can get around the error by setting supports_ddl_transaction? to false in the adapter, but that doesn’t feel right as Sqlite3 does support DDL in transactions.