[sqlalchemy] Re: Multiple SQLAlchemy DB usage in TurboGears
Michael: Thanks, I've gone the per-request route for the moment. The reason we're behind on SQLA versions is that the TurboGears we started on a year ago used that particular version; we do have TurboGears upgrade plans in place, so that'll be sorted out soon enough. Barry: I've left the Visit information in a database-per-customer as the Visit table relies on the User table (which we need for other joins), and I don't feel like ensuring that it only ever used the primary key as an integer (and therefore breaking the foreign key relationship). Thanks for the comments re. Identity though. Bryn On May 9, 2:54 am, Barry Hart <[EMAIL PROTECTED]> wrote: > The identity and visit stuff is pluggable, i.e. you can replace the existing > components without hackery; just write your own and specify which one to use > in the application .cfg file. This probably sounds more intimidating than it > is; the code is really pretty straightforward and you can use their > implementations as a starting point. > > You might consider using a single (separate) database to store all visit > information for *all* the customers combined. Your visit schema could have an > additional 'customer' column to distinguish which database to use for > everything else. > > Barry > > - Original Message > From: Michael Bayer <[EMAIL PROTECTED]> > To: sqlalchemy@googlegroups.com > Sent: Thursday, May 8, 2008 5:05:22 PM > Subject: [sqlalchemy] Re: Multiple SQLAlchemy DB usage in TurboGears > > On May 8, 2008, at 11:15 AM, Bobby Impollonia wrote: > > >> I'd try bypassing their SQLA integration altogether if thats possible > > > It isn't possible if you are relying on the turbogears identity system > > (cookie-based visitor tracking and access control). > > that sounds like a particular set of mappings and classes. theres no > issue using those; I was talking about their Session integration. > > > > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple SQLAlchemy DB usage in TurboGears
The identity and visit stuff is pluggable, i.e. you can replace the existing components without hackery; just write your own and specify which one to use in the application .cfg file. This probably sounds more intimidating than it is; the code is really pretty straightforward and you can use their implementations as a starting point. You might consider using a single (separate) database to store all visit information for *all* the customers combined. Your visit schema could have an additional 'customer' column to distinguish which database to use for everything else. Barry - Original Message From: Michael Bayer <[EMAIL PROTECTED]> To: sqlalchemy@googlegroups.com Sent: Thursday, May 8, 2008 5:05:22 PM Subject: [sqlalchemy] Re: Multiple SQLAlchemy DB usage in TurboGears On May 8, 2008, at 11:15 AM, Bobby Impollonia wrote: > >> I'd try bypassing their SQLA integration altogether if thats possible > > It isn't possible if you are relying on the turbogears identity system > (cookie-based visitor tracking and access control). that sounds like a particular set of mappings and classes. theres no issue using those; I was talking about their Session integration. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple SQLAlchemy DB usage in TurboGears
On May 8, 2008, at 11:15 AM, Bobby Impollonia wrote: > >> I'd try bypassing their SQLA integration altogether if thats possible > > It isn't possible if you are relying on the turbogears identity system > (cookie-based visitor tracking and access control). that sounds like a particular set of mappings and classes. theres no issue using those; I was talking about their Session integration. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple SQLAlchemy DB usage in TurboGears
> I'd try bypassing their SQLA integration altogether if thats possible It isn't possible if you are relying on the turbogears identity system (cookie-based visitor tracking and access control). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple SQLAlchemy DB usage in TurboGears
On May 8, 2008, at 10:55 AM, Bryn Divey wrote: > > We're building an application on TG 1.0.2 using SQLAlchemy 0.3.11 are > are busy considering our options wrt multiple customer support. We'd > be hosting the app servers, and there's a low upper-bound to the > traffic they'll be hit with, so we're trying to figure out a way to > support multiple customers on a single app instance. we're going to be merging the 0.5 branch to trunk soon - 0.5 features better transaction integration and much cooler Query object. Why start off using 0.3.11 ? That version is ancient history, is 20% slower than 0.4 and probably 30% slower than 0.5. you should at least be on 0.4.5 so that your upgrade path to 0.5 is not very painful. > The problem is that the system is quite complex and there were > limitations which made making our DB schemas multi-customer rather > difficult. This means that we'd basically need to figure out - per > request - which customer we're working with, and load their database > up for the lifetime. An experimental solution exists which hijacks > things like turbogears.database.get_engine and replaces them with a > function which determines the correct engine to be loaded. I'm still > wading through it to try get it up and running again (I'm getting > Visit attached to incorrect session errors atm.) I dont know about TG's integration but a per-request engine setup is a very reasonable (and typical) way to go.I'd try bypassing their SQLA integration altogether if thats possibleall you need is a ScopedSession, plug in the engine on each request, and you're ready to go. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
