Hacker News Reader

Comment by jacobkg | Hacker News Reader

The multiple database support is really exciting. Anything that makes it easier to push database reads to replicas is huge!

View on HN

The cool thing about multi-database feature that's coming to Rails is setting like

>config.active_record.database_selector = 2.seconds

Rails provides a way to make sure that at-least for first two seconds after the write operation, read requests are handled by the write instance. This assumes that your read replica will get updated within 2 seconds with the live data.

How cool is that

How does that work though? If you have multiple instances that are serving the same traffic, how do one know about the change made by the other? Is it a global timer? i.e. any write affects reads, or it knows and only works on the same table?

Why not keep dependent operations within the same transaction? If that would be done by rails from the start then I could just easily split read/write through pgpool.

It is read-your-writes semantics, and the metadata is stored in the session.

We've been doing this for years on a Rails 3 app. We yield from a `slave` method, with the connection pointing to the replica DB until yield returns. It's just a short method. It's great if Rails now supports this directly, but a shame if people have been waiting for it.

Ditto, though we started this behavior in Rails 3 or 4, I no longer recall, and are now on 5.2.X.

Reply on news.ycombinator.com