Separate databases for reads and writes?

Hi all -

New to rails… been reading as much as I can though and have yet to
find
a solid answer (although I think I found an unsolid negative).

I’m wondering if there’s a way to split up the reads and writes in Rails
so that pages/actions that don’t need to write can query from a group of
mirrored databases. And my content managers can update a single master.

I know I could do it if I broke the application up into two, but that
seems the wrong way to go about it.

So far I’ve found these two references, neither super encouraging…

http://wrath.rubyonrails.org/pipermail/rails-core/2005-November/000276.html
http://dev.rubyonrails.org/ticket/2041

Any change since then?

Thanks!

-philip

On 4/19/06, Philip H. [email protected] wrote:

I’m wondering if there’s a way to split up the reads and writes in Rails
so that pages/actions that don’t need to write can query from a group of
mirrored databases. And my content managers can update a single master.

Just making this up as I go along, this is ugly and may not work at
all. Inspiration
came from:
http://wiki.rubyonrails.com/rails/pages/HowtoUseMultipleDatabases
http://blogs.pragprog.com/cgi-bin/pragdave.cgi/Tech/Ruby/Connections.rdoc

Model:
class Model < ActiveRecord::Base

end

class ReadModel1 < Model
  set_table_name "models"
  establish_connection ...
end

class ReadModel2 < Model
  set_table_name "models"
  establish_connection ...
end

...

class ReadModelN < Model
  set_table_name "models"
  establish_connection ...
end

class WriteModel < Model
  set_table_name "models"
  establish_connection ...
end

Managers Controller:
def list
@models = WriteModel.find :all
end

Users Controller:
@@connections = [ReadModel1, ReadModel2, … ReadModelN]

def list
  read_model = @@connections[rand N]
  @models = read_model.find :all
end

Assuming this works at all :-), an enhancement would be to store which
model
class to use in the session once and reuse the same connection for the
rest
of that session.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs