Hi, I''m in a situation where I''d like to share the exact same DB structure, controllers, helpers, models and views between two "teams". Each "team" needs a separate DB that has identical structure but different data. So here''s the question: How do I go about setting this up? I''d like to do it by subdomain (but I''ve never even tried to set one up, so I''m lost), but would settle for a field on a User class that I can check when they login to know what team''s DB to use. Basically the idea is I need multiple production DBs, but would like to share common code and structure across them. Any thoughts? Thanks, Chris _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
http://wiki.rubyonrails.com/rails/show/HowToUseSubdomainsAsAccountKeys and http://wiki.rubyonrails.com/rails/show/HowtoUseMultipleDatabases Might help you Chris On Mon, 28 Feb 2005 11:24:36 -0500, Williams, Chris <Chris.Williams-yLTBD9Em4aGakBO8gow8eQ@public.gmane.org> wrote:> > > Hi, > > I''m in a situation where I''d like to share the exact same DB > structure, controllers, helpers, models and views between two "teams". Each > "team" needs a separate DB that has identical structure but different data. > > So here''s the question: How do I go about setting this up? I''d like to do it > by subdomain (but I''ve never even tried to set one up, so I''m lost), but > would settle for a field on a User class that I can check when they login to > know what team''s DB to use. > > Basically the idea is I need multiple production DBs, but would like to > share common code and structure across them. > > Any thoughts? > > Thanks, > Chris > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
> -----Original Message----- > From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails- > bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Steven Critchfield > Sent: Monday, February 28, 2005 12:32 PM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails] Swapping DBs based on subdomains > > On Mon, 2005-02-28 at 11:24 -0500, Williams, Chris wrote: > > Hi, > > > > I''m in a situation where I''d like to share the exact same DB > > structure, controllers, helpers, models and views between two"teams".> > Each "team" needs a separate DB that has identical structure but > > different data. > > > > So here''s the question: How do I go about setting this up? I''d liketo> > do it by subdomain (but I''ve never even tried to set one up, so I''m > > lost), but would settle for a field on a User class that I can check > > when they login to know what team''s DB to use. > > > > Basically the idea is I need multiple production DBs, but would like > > to share common code and structure across them. > > While splitting the teams up by database would probably use the least > amount of code change, it might throw up future barriers using tools > like memcached as you will have to know what database the recordswhere> pulled from. > > You could alternately go in and add an ID to link specific records to > the team that is working with it.Well it''s even an issue of security. The teams don''t want the others to see they''re data. It seemed best to just clone the DB structure and let each have their own to store data - and swapping the DB based on subdomain looked like the easiest way to keep the code looking like I just needed to deal with a single team''s data. Thanks, Chris
On Mon, 2005-02-28 at 11:24 -0500, Williams, Chris wrote:> Hi, > > I’m in a situation where I’d like to share the exact same DB > structure, controllers, helpers, models and views between two “teams”. > Each “team” needs a separate DB that has identical structure but > different data. > > So here’s the question: How do I go about setting this up? I’d like to > do it by subdomain (but I’ve never even tried to set one up, so I’m > lost), but would settle for a field on a User class that I can check > when they login to know what team’s DB to use. > > Basically the idea is I need multiple production DBs, but would like > to share common code and structure across them.While splitting the teams up by database would probably use the least amount of code change, it might throw up future barriers using tools like memcached as you will have to know what database the records where pulled from. You could alternately go in and add an ID to link specific records to the team that is working with it. -- Steven Critchfield <critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org>
Steve,> > Hi, > > > > I''m in a situation where I''d like to share the exact same DB > > structure, controllers, helpers, models and views between two"teams".> > Each "team" needs a separate DB that has identical structure but > > different data. > > > > So here''s the question: How do I go about setting this up? I''d liketo> > do it by subdomain (but I''ve never even tried to set one up, so I''m > > lost), but would settle for a field on a User class that I can check > > when they login to know what team''s DB to use. > > > > Basically the idea is I need multiple production DBs, but would like > > to share common code and structure across them. > > While splitting the teams up by database would probably use the least > amount of code change, it might throw up future barriers using tools > like memcached as you will have to know what database the recordswhere> pulled from. > > You could alternately go in and add an ID to link specific records to > the team that is working with it. > -- > Steven Critchfield critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.orgThis is the approach I originally took, but it led to some ugly code and DB round-trips I didn''t like. For a lot of pages and pull-down menus I had to get the logged in user, pull down their team, then filter the rest of the data by the team. It was ugly. If I can make the user explicitly choose their team by the subdomain they enter and then use that assumption inside the associations and pages it makes everything much, much cleaner. Thanks, Chris
Chris,> http://wiki.rubyonrails.com/rails/show/HowToUseSubdomainsAsAccountKeys > > and > > http://wiki.rubyonrails.com/rails/show/HowtoUseMultipleDatabases > > Might help you > > ChrisThanks, they did help. Just to share information for everyone, I kept running into problems using the examples verbatim. I inserted the hijack_db method and before_filter into my application controller. The problem was that I also do authentication and carry a User object in the session. So I was forced to include "model :user" inside the application controller. This caused Rails to barf if I didn''t have a connection set up. So what I had to do was stick the users table in the DB for my environment (if I stuck to the config DBs). Its ugly, but it works. So I always hijack the DB before anything important happens, but I do need to provide tables for model objects carried in the session in the DB setup by database.yml. Thanks, Chris
On Tue, 2005-03-01 at 09:41 -0500, Williams, Chris wrote:> Steve, > > > > Hi, > > > > > > I''m in a situation where I''d like to share the exact same DB > > > structure, controllers, helpers, models and views between two > "teams". > > > Each "team" needs a separate DB that has identical structure but > > > different data. > > > > > > So here''s the question: How do I go about setting this up? I''d like > to > > > do it by subdomain (but I''ve never even tried to set one up, so I''m > > > lost), but would settle for a field on a User class that I can check > > > when they login to know what team''s DB to use. > > > > > > Basically the idea is I need multiple production DBs, but would like > > > to share common code and structure across them. > > > > While splitting the teams up by database would probably use the least > > amount of code change, it might throw up future barriers using tools > > like memcached as you will have to know what database the records > where > > pulled from. > > > > You could alternately go in and add an ID to link specific records to > > the team that is working with it. > > -- > > Steven Critchfield critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org > > This is the approach I originally took, but it led to some ugly code and > DB round-trips I didn''t like. For a lot of pages and pull-down menus I > had to get the logged in user, pull down their team, then filter the > rest of the data by the team. It was ugly. > > If I can make the user explicitly choose their team by the subdomain > they enter and then use that assumption inside the associations and > pages it makes everything much, much cleaner.Understandable, but it doesn''t stop you from still breaking the database with team_id fields. You just parse the host name and grab the appropriate id number. There''s nothing stopping you from caching the team name or id in the @session variable and using it to eliminate the multiple round trips per page. -- Steven Critchfield <critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org>