Michael Bayer wrote: >> Thanks I'll take a look. I left out what I think is an >> important part of this scenario (or maybe it's trivial - I don't >> have a good perspective on this yet). In any case, I would like >> to use the ORM component of sqlalchemy and completely hide the >> fact that the read/ write connections are possibly different. >> (They might become the same connection if the local database >> becomes unaccessible and/or is too far behind the master). > > that is going to be very hard to accomplish as the Session does > not have a clustering rules engine built into it in order to > determine read/write locations, nor is that within its scope. It > can only handle "class X talks to engine Y".
Just an FYI, I am actually splitting reads and writes in a fairly straightforward way in my web application by inferring the intent of the request based upon the method. We developed the application so that all requests that write to the database are in a POST. Everything else uses other methods (primarily GET). We use a scoped session, ensuring that each request gets its own session and then wrote some WSGI middleware which will automatically bind the session to the correct database instance (one of the masters, or the correct slave) based upon the request method. We also automatically wrap POST's in a transaction, and roll back upon errors. FWIW, this middleware is like 20 lines of code long. If your app is not web-based you might have trouble getting away with something like this :) -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
