My development timeframe is "when it's ready". (It's a personal project, so the only driving force is the angst of the thousand people who use the service and pay nothing for it. In other words -- no rush!)
Considering what I'm looking to do, I'd be more than willing to wait... and more than willing to help (developing, testing, etc.) accelerate the AR3/multi-tenancy support initiative so I don't have to wait so long. ;) Do you have a branch for AR3 yet? On Jun 15, 3:14 pm, Markus Zywitza <[email protected]> wrote: > What is your development timeframe? Multi-tenancy is one of the major new > features I envision for AR3. If you say, we will have this going by the end > of the year, you might start with plain AR. The multi-tenancy support will > be added along the lines of: > using (new SessionScope("tenant-id")) > { > // regular AR like before > > } > > By using this, each tenant can have its own session factory along with all > options this enables (such as different RDBMS types or custom listeners per > tenant). > > In conjunction with MonoRail, this boils down to a filter which reads the > tenant from the request and starts the SessionScope for the request. If I > have a user for early adoption and regular feedback, I will be happy to code > this story as one of the first after release of AR2. > > -Markus > > 2009/6/15 Brian DeMarzo <[email protected]> > > > > > The Environment: MonoRail, ActiveRecord, Windsor with AR Facility > > > The Situation: I have one database schema and many databases built > > using that schema. A web application will dynamically figure out which > > one of those databases it is connecting to based on the URL, and will > > need to adjust the database connection string for that request prior > > to any controller processing. (The application is indifferent to which > > database it connects to, since they are all the same schema, just > > different data.) Multiple config files or base classes to handle > > multiple DBs is not possible, as the number of databases could change > > at any time (it's a very dynamic system). > > > This is an existing app that is being rewritten. It's a baseball game > > with a single huge (~190GB) database, and 98% of the data in that DB > > can be split at the "league" level (about 150 leagues). I'm thinking > > of switching from one big DB to many small DBs for better scaling and > > performance (at the expense of manageability). > > > The Issue: What is the best way to handle this? > > > I've searched for answers to this before, and have found a few > > different suggestions, so this post is as much a summary of those > > things as well as a call for suggestions on whether anything I've > > found so far is right, or if there are other solutions. > > > Some of the suggestions I've found: > > > 1. Use a custom NHibernate connection provider and inject the > > connection string based on the HttpContext. Side effect: This breaks > > the 2nd level cache, which I perhaps can live with. > > 2. Implement and manage multiple session factories using a solution > > such ashttp://www.codeproject.com/KB/aspnet/NHibernateMultipleDBs.aspx. > > 3. Use DifferentDatabaseScope in AR -- though comments have said that > > this isn't fully baked yet, this seems to do something similar as #1 > > above. > > 4. Wait for NHibernate.Shards to fully bake, and look to incorporate > > that. > > 5. Rely on SQL 2005's horizontal partitioning to avoid the multi-db > > problem and keep everything into a single DB. (Not really a solution > > based on my requirements, but it is an option.) > > > I'd prefer not to abandon AR or the facility, though I would be > > willing to remove it and just use the NH facility if necessary. > > > Any thoughts on the matter? At this point, it seems that a custom NH > > connection provider and no 2nd level cache seems most straight-forward > > and reliable. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
