diff --git a/README.md b/README.md index 5acaa9d..b49b10a 100644 --- a/README.md +++ b/README.md @@ -4,10 +4,10 @@ **Self-hosted, distributed Durable Objects in Rails without a daemon using your existing SQL database.** -Solid Objects brings the Durable Objects programming model—addressable objects, -durable state, serialized turns, alarms, and live clients—to ordinary Rails -applications. It runs on the MySQL, PostgreSQL, or SQLite database the -application already has, following the database-backed operating model of the +Solid Objects ports the Durable Objects programming model to ordinary Rails +applications: addressable objects, durable state, serialized turns, alarms, +and live clients. It runs on the MySQL, PostgreSQL, or SQLite database that +the application already has, in the database-backed operating model of the Solid family. No Redis, Cloudflare account, or separate actor service is required. @@ -113,7 +113,7 @@ maps those ideas into Rails: | Storage deletion | Authorized `reference.destroy` | | Cloudflare Workers platform | Your Rails processes and SQL database | -Rails already has excellent tools for jobs, records, and realtime transport. +Rails already has tools for jobs, records, and realtime transport. None of those primitives alone provides this complete stateful-object shape. Solid Objects adds five capabilities: @@ -1273,7 +1273,7 @@ for staged cutovers. | --- | --- | | Cloudflare Durable Objects | Solid Objects ports the named, stateful, serialized-object model to Ruby and Rails. It uses your SQL database and Rails workers rather than Cloudflare's globally distributed serverless runtime, placement, and storage APIs. | | Active Job | Jobs are independent work units. Solid Objects adds addressable identity, durable state, explicit per-identity order, activation leases, and fencing. | -| Solid Queue | Solid Queue is an excellent database backend for Active Job. Its concurrency controls cap overlap but do not guarantee order. Solid Objects provides actor mailboxes, state, fencing, per-identity reminders, and state-driven views. | +| Solid Queue | Solid Queue is a database backend for Active Job. Its concurrency controls cap overlap but do not guarantee order. Solid Objects provides actor mailboxes, state, fencing, per-identity reminders, and state-driven views. | | Action Cable | Cable transports transient realtime messages. Solid Objects owns durable state and work; Cable is an optional delivery path for committed observable projections. | | Orleans | Orleans provides the virtual-actor lineage behind the model, with grains, reminders, and activation lifecycle. Solid Objects is a smaller Rails-native runtime and does not match Orleans clustering or placement breadth. | | Active Record service object | A service object runs directly against records. Solid Objects adds durable asynchronous ordering, retries, activation fencing, reminders, and outboxes at greater operational cost. | diff --git a/docs/research/solid_queue.md b/docs/research/solid_queue.md index fd862bc..17e4046 100644 --- a/docs/research/solid_queue.md +++ b/docs/research/solid_queue.md @@ -526,8 +526,8 @@ Source: [Cloudflare Durable Objects overview](https://developers.cloudflare.com/ - Solid Queue findings are tied to v1.6.0. Earlier releases did not have all current async/fiber supervision and concurrency finalization behavior. - PostgreSQL documentation inspected was current PostgreSQL 18 documentation. `SKIP LOCKED` has existed since PostgreSQL 9.5, but Solid Objects supports PostgreSQL 14 and newer. - MySQL documentation inspected was MySQL 8.4. Solid Objects supports MySQL 8.0 and newer with InnoDB. -- SQLite documentation inspected covers current SQLite behavior. Solid Objects requires SQLite 3.35 or newer for modern DML support. -- Rails documentation and source inspected cover Rails 8.1. Solid Objects requires Rails 8.0 or newer because Rails 8 changed the SQLite adapter's default write transaction from deferred to immediate, which the SQLite coordination contract relies on. +- SQLite documentation inspected covers current SQLite behavior. Solid Objects supports SQLite 3.35 or newer, the oldest server version the adapter accepts. +- Rails documentation and source inspected cover Rails 8.1. Solid Objects requires Rails 7.1 or newer. Rails 8 changed the SQLite adapter's default write transaction from deferred to immediate, and the test suite also passes on Rails 7.1 and 7.2 with the deferred default. Rails 7.0 stays out of range because its SQLite adapter requires sqlite3 1.4, and the busy-handler control this gem depends on arrived in sqlite3 2.x. - Orleans documentation describes current Orleans behavior, not a compatibility promise for this Ruby implementation. - `LISTEN/NOTIFY` and Action Cable are optimizations and delivery channels, never durable truth. - A separate actor database is compatible only when all rows participating in an atomic actor commit, including message, state, effects, and broadcasts, live in that same actor database. diff --git a/docs/state-migrations.md b/docs/state-migrations.md index e8f33fe..a370b51 100644 --- a/docs/state-migrations.md +++ b/docs/state-migrations.md @@ -47,6 +47,6 @@ A safe destructive rollout normally uses: Never update actor JSON in a bulk SQL migration. Use actor messages so fencing, ordering, observables, and outboxes remain intact. -This guide covers evolution after state belongs to Solid Objects. For moving +This guide covers changes to state that Solid Objects already owns. To move existing Redis, key-value, or relational state into actors without downtime, use the [legacy-state migration cookbook](migrating-existing-state.md).