As a result of stumbling across The state of Riak Core, Lasp and distributed programming in BEAM from ~ 3 years ago, I am now looking at:
however, it is not clear to me what problems these two libraries solve. I also admit that the descriptions in the documentation are not making as much sense to me. Here is how I want to phrase the question:
- You are writing an application on Erlang/Elixir + OTP.
- You run into some concrete problem XYZ.
- You conclude: aha! this is now the right time to use riak_core / lasp.
What are concrete examples of XYZ ?
Sorry to necro. Seems like XYZ is “I want to create an app that can be transparently distributed – both in code and data”. I might be a little off-mark but it seems that both libraries aim to provide building blocks with which some of the friction of building distributed apps / data is taken care of for you. How exactly though, I don’t know, haven’t used them.
Don’t use Riak core is way too crufty to drop into an elixir project. Use the cleaned up fork riak-core-lite. The project page gives a pretty good idea what it’s good for.
5 Likes
@bryanhuntesl : If you have experience with riak-core-(lite?) / lasp, however random, I’m interested in hearing them.
These libraries seem “one level up” from genserver / otp, in the context of building distributed systems.
I am surprised there are not as many books/articles on them.
lasp seems interesting but I’ve never known anyone using it in production and it seemed more on the academic side. for production distributed storage we’re mostly using cockroachdb. riak-core-lite website has some really easy to run examples for build your own database/build your own distributed worker system.
3 Likes
Today I tried cockroachdb v21.1.6, but failed running mix ecto.migrate. I’m using the original postgrex because the version of the patched postgrex seems too low.
Here’s the error:
** (MatchError) no match of right hand side value: {:error, %Postgrex.Error{connection_id: 0, message: nil, postgres: %{code: :syntax_error, detail: "source SQL:\nLOCK TABLE \"schema_migrations\" IN SHARE UPDATE EXCLUSIVE MODE\n^", file: "lexer.go", line: "215", message: "at or near \"lock\": syntax error", pg_code: "42601", routine: "Error", severity: "ERROR"}, query: "LOCK TABLE \"schema_migrations\" IN SHARE UPDATE EXCLUSIVE MODE"}}
(ecto_sql 3.6.2) lib/ecto/adapters/postgres.ex:222: anonymous fn/3 in Ecto.Adapters.Postgres.lock_for_migrations/3
(ecto_sql 3.6.2) lib/ecto/adapters/sql.ex:1017: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4
(db_connection 2.4.0) lib/db_connection.ex:1512: DBConnection.run_transaction/4
(ecto_sql 3.6.2) lib/ecto/adapters/postgres.ex:217: Ecto.Adapters.Postgres.lock_for_migrations/3
(ecto_sql 3.6.2) lib/ecto/migrator.ex:493: Ecto.Migrator.lock_for_migrations/4
(ecto_sql 3.6.2) lib/ecto/migrator.ex:388: Ecto.Migrator.run/4
(ecto_sql 3.6.2) lib/ecto/migrator.ex:146: Ecto.Migrator.with_repo/3
(ecto_sql 3.6.2) lib/mix/tasks/ecto.migrate.ex:133: anonymous fn/5 in Mix.Tasks.Ecto.Migrate.run/2
(elixir 1.12.2) lib/enum.ex:2385: Enum."-reduce/3-lists^foldl/2-0-"/3
(ecto_sql 3.6.2) lib/mix/tasks/ecto.migrate.ex:121: Mix.Tasks.Ecto.Migrate.run/2
(mix 1.12.2) lib/mix/task.ex:394: anonymous fn/3 in Mix.Task.run_task/3
(mix 1.12.2) lib/mix/cli.ex:84: Mix.CLI.run_task/2
(elixir 1.12.2) lib/code.ex:1261: Code.require_file/2
I tried directly execute the following query in cockroach console
lock table "schema_migrations" in share update exclusive mode;
and it gives me
invalid syntax: statement ignored: at or near "lock": syntax error
SQLSTATE: 42601
DETAIL: source SQL:
lock table "schema_migrations" in share update exclusive mode
^
Blind suggestion: check the version?
In use:
- CockroachDB: v21.1.6
- Phoenix: 1.5.9
- Ecto: 3.6.2
- Postgrex: 0.15.9
Tried but not working
- ecto_cockroachdb: 1.0.0
- postgrex_cdb: 0.13.5 (latest)
Ecto 3.6.2 requires postgrex ~> 0.15.0 or ~> 1.0, so postgrex_cdb can’t be used.
ecto_cockroachdb doesn’t implement the callback lock_for_migrations
So it seems you already know the problem. 
Yup. It seems the only way is to copy and modify Ecto.Adapters.Postgres and make a new CockroachDB adapter without table-level locking.
I think you can set migration_lock: false in your Repo config in order to let the migrations run.
1 Like
Good to know. I’ll try it. Thanks 
It works! Thanks so much!
1 Like
That shouldn’t be happening. We are just using stock Postgrex drive across our projects and no such issue. There was an issue with default timestamp precision which affected Ecto migrations but was fixed ages ago. I’ll set a reminder and check this on Monday.
Ok , just checked the dependencies. Our developer used ecto_cockroachdb .
{:ecto, "== 3.5.8"},
{:ecto_cockroachdb, "~> 1.0.0"}
The lock table thing doesn’t seem like the best approach. Obviously, CockroachDB doesn’t do table locking (would destroy performance in such a system) although it is doing a form of locking a the table row level (RAFT consensus).
What might be better (and work everywhere, would be to run the migration (and table update) in serializable transaction mode)).
We are on 3.5.8, @Aetherus is there a specific reason you’ve upgraded to 3.6.2? (I’m trying to map out our upgrade roadmap).
1 Like
I think you can set migration_lock: false in your Repo config in order to let the migrations run.
On another note, we’re running on Kubernetes, and each container is set to run the migrations on startup. If we turn off the locking (or ecto_cockroachdb) is doing this, that might be quite dangerous for our deployments.
Really glad I got notified by this thread.
is there a specific reason you’ve upgraded to 3.6.2?
No specific reason. I’m just creating a new phoenix project with the default deps.
If we turn off the locking (or ecto_cockroachdb) is doing this, that might be quite dangerous for our deployments.
I can vaguely sense the dangers, but not very clear.
PostgreSQL’s SHARE UPDATE EXCLUSIVE mode does not lock the table for CRUD. It just locks the table for concurrent schema changes and VACUUM. See PostgreSQL: Documentation: 16: 13.3. Explicit Locking. If the migration scripts are executed sequentially, I guess it doesn’t matter whether adding such lock or not.
Could you give an example of some danger I’m not aware of?
Ok, just checked the dependencies. Our developer used ecto_cockroachdb .
{:ecto, "== 3.5.8"},
{:ecto_cockroachdb, "~> 1.0.0"}
The lock table thing doesn’t seem like the best approach. Obviously, CockroachDB doesn’t do table locking (would destroy performance in such a system) although it is doing a form of locking a the table row level (RAFT consensus).
What might be better (and work everywhere, would be to run the migration (and table update) in serializable transaction mode)).
We are on 3.5.8, @Aetherus is there a specific reason you’ve upgraded to 3.6.2? (I’m trying to map out our upgrade roadmap).
@Aetherus (i has this response in draft for some reason so there’s a slight context drift). To answer your question about the risk, I’m a little concerned about race conditions if migrations run simultaneously on separate nodes, sometimes we might launch 10 instances of the service simultaneously and let them fight it out to perform the database migration first.
