cainophile
rethinkdb_rebirth
| cainophile | rethinkdb_rebirth | |
|---|---|---|
| 2 | 1 | |
| 234 | 1,016 | |
| 1.3% | - | |
| 1.7 | 0.0 | |
| 2 months ago | about 5 years ago | |
| Elixir | C++ | |
| Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cainophile
-
How to Listen to Database Changes Using Postgres Triggers in Elixir
If you want to listen to database changes in Elixir you can also get really good stuff done by using Cainophile (https://github.com/cainophile/cainophile). Same mechanism. I don't know the details of Debezium so I can't say if you are leaving fantastic things on the table. But I've had good fun with Cainophile. For example I've used it in my videos on Electric SQL to react to changes in a Postgres database. It matches nicely with realtime-ish UI via LiveView. So meshes really good with the current Elixir stack.
-
Ask HN: Is there a way to subscribe to an SQL query for changes?
https://github.com/cainophile/cainophile
I happened to do a similar thing but I adapted cainophile into an Elixir “OffBroadway” producer:
rethinkdb_rebirth
-
Ask HN: Is there a way to subscribe to an SQL query for changes?
I know [RethinkDB][1] used to do this with their SQL-like ReQL language, but I looked around a bit and can't find much else about it - and I would have thought it would be more common.
If we think about modern frontends using SQL-based backends, essentially every time we render, its ultimately the result of a tree of SQL queries (queries depend on results of other queries) running in the backend. Our frontend app state is just a tree of materialized views of our database which depend on each other. We've got a bunch of state management libraries that deal with trees but they don't fit so well with relational/graph-like data.
I came across a Postgres proposal for [Incremental View Maintenance][2] which generates a diff against an existing query with the purpose of updating a materialized view. Oracle also has [`FAST REFRESH`](https://docs.oracle.com/database/121/DWHSG/refresh.htm#DWHSG8361) for materialized views.
I guess it's relatively easy to do until you start needing joins or traversing graphs/hierarchies - which is why its maybe avoided.
[1]: https://github.com/rethinkdb/rethinkdb_rebirth
What are some alternatives?
noria - Fast web applications through dynamic, partially-stateful dataflow
realtime - Broadcast, Presence, and Postgres Changes via WebSockets
supavisor - A cloud-native, multi-tenant Postgres connection pooler.
Hasura - Blazing fast, instant realtime GraphQL APIs on your DB with fine grained access control, also trigger webhooks on database events.
timely-dataflow - A modular implementation of timely dataflow in Rust
flow - 🌊 Continuously synchronize the systems where your data lives, to the systems where you _want_ it to live, with Estuary Flow. 🌊
PipelineDB - High-performance time-series aggregation for PostgreSQL
db_watch
revori - A revision-oriented DBMS