Part 7: Multi db improvements, Add ability to block writes to a database

[eileencodes]

We use this at GH but I'm not 100% sure whether others will find this useful. Thoughts?

The other open question I have is whether the write_query? should be defined by "is a query that writes" or "is a query that is not reading" (ie not select, etc). For now I chose some common write queries to demonstrate the goals of this feature but I'd love input into what @rafaelfranca @tenderlove and @matthewd think about this.

---

This PR adds the ability to block writes to a database even if the
database user is able to write (ie the database is a primary and not a
replica).

This is useful for a few reasons: 1) when converting your database from
a single db to a primary/replica setup - you can fix all the writes on
reads early on, 2) when we implement automatic database switching or
when an app is manually switching connections this feature can be used
to ensure reads are reading and writes are writing. We want to make sure
we raise if we ever try to write in read mode, regardless of database
type.

This should be used in conjunction with connected_to in write mode.
For example:

ActiveRecord::Base.connected_to(role: :writing) do
  Dog.connection.while_blocking_writes do
    Dog.create! # will raise because we're blocking writes
  end
end

ActiveRecord::Base.connected_to(role: :reading) do
  Dog.connection.while_blocking_writes do
    Dog.first # will not raise because we're not writing
  end
end

[rafaelfranca]

We do have code to do the same thing. So this would be useful for us.

We define it as "is a query that is not reading" (ie not select, etc)", and we use:

      build_union_regexp = ->(*parts) do
        parts = parts.map { |part| /\A\s*#{part}/i }
        Regexp.union(*parts)
      end
      READ_QUERY = build_union_regexp.call(:select, :show, :set)

as definition.

[matthewd]

I like the idea of it, because it'd provide a good foundation to run a read/write-split application against a single database in development.

I don't think it's practical to detect read-only queries via string matching, though: even something that explicitly starts with "SELECT" can end up writing. I wonder about using SET SESSION TRANSACTION READ ONLY to have the DB enforce it instead? (Also worth noting I believe most write-ish queries go via execute, not exec_query.)

On a specific API note, I'd prefer a synonym for 'blocking', just because it conflicts with "[thread] blocking I/O".

[eileencodes]

Changed while_blocking_writes to while_preventing_writes to address @matthewd's concern. I also updated the SQL matcher to use the regex from @rafaelfranca and added some more tests.

[eileencodes]

Oh right I also need to move this to execute. 😄

[paracycle]

I agree with @matthewd that detecting read-only queries via string matching might be problematic. For example SELECT ... INTO is definitely not a read-only query but would pass the check. I am not sure what the best alternative is, though, but making the DB enforce it sounds much better.

[eileencodes]

Ok I moved this to execute and added tests for create/delete/update/where.first to ensure these were all getting caught.

I updated the changelog to note that the purpose of preventing write queries when choosing readonly mode is for testing, catching accidental writes, and for switching to a readonly connection without opening a second connection. It's purpose isn't to catch ALL writes to a database - it's not meant as a replacement for a replica.

[Fivell]

@eileencodes what about copy to CSV ? in this implementation it is going to be writable but it isn't

[bogdan]

explain ?

[eileencodes]

Explain is on master.

rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb

Line 66 in 72005ad

DEFAULT_READ_QUERY = [:begin, :commit, :explain, :release, :rollback, :savepoint, :select, :with] # :nodoc:

[eileencodes]

what about copy to CSV

This feature is not meant to be a catch all. If you want to actually block all writes you should use a readonly user.

[Fivell]

@eileencodes I don't want to block writes, just expect using copy to csv will not raise error created issue #39166

[janko]

I'm curious, why was this approach preferred over read-only transactions, which @matthewd had mentioned in #34505 (comment)? Extending Active Record transactions to support a new option e.g. :read_only that would set READ ONLY access mode seems much simpler, and also more correct because it would be leveraging the database instead of regex-matching SQL strings.

[eileencodes]

I answered @janko here https://discuss.rubyonrails.org/t/active-record-while-preventing-writes-api-versus-read-only-transactions/76443/2.

Can we keep the discussion in one place if there are followup questions? Thanks!

[h0jeZvgoxFepBQ2C]

I agree with @matthewd that detecting read-only queries via string matching might be problematic. For example SELECT ... INTO is definitely not a read-only query but would pass the check. I am not sure what the best alternative is, though, but making the DB enforce it sounds much better.

So is this merge now safe against a SELECT ... INTO ?