Thanks for the replies. I'll have to take a while to digest the comments and suggestions to see how I'm going to proceed.
I'm sort of in an initial trial mode working a few hours here and there to get an idea if using sqlalchemy is feasible. I'm expecting it will be and I'll probably just forge ahead and do whatever it takes to get something working. Right now we are using mysqldb and hand crafted sql strings and my own very lightweight (er, dumb) read only ORM layer. Unfortunately I'll need to slowly introduce sqlalchemy in little bits since the system is too huge to even consider a frankenstein switch from one method to another. I'm most intruiged by the mysql_proxy idea. This would be a win for us even if for some reason I don't get purchase on introducing sqlalchemy to our system. I'm assuming that sqlalchemy in this scenario isn't even aware of the proxy level at all. thanks On Jun 9, 12:44 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > we're also assuming that you've exhausted these approaches (which > would be a lot more appropriate for this sort of thing): > > http://forge.mysql.com/wiki/MySQL_Proxyhttp://dev.mysql.com/doc/refman/5.0/en/replication.html > > On Jun 9, 2008, at 2:22 PM, qhfgva wrote: > > > > > On Jun 6, 12:34 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > >> On Jun 6, 2008, at 2:29 PM, qhfgva wrote: > > >>> We have (what I think of as) a moderately complicated database > >>> configuration and I'm hoping there will be a way to configure > >>> sqlalchemy to deal with it. The basic scenario is like this: > > >>> There are N mysql servers in different geographical regions that are > >>> all replicating against one master. In the interest of speed the > >>> rule > >>> in each location is to do reads which are very frequent against the > >>> local copy of the database and if there is a write to do that > >>> against > >>> the master. As an added wrinkle the user has an option to write to > >>> the master with a master_pos_wait so that the current process will > >>> wait until replication has caught up with the update just executed. > >>> Hopefully that makes sense and gives enough of a flavor of what I've > >>> got in mind. > > >>> I'm pretty new to sqlalchemy. Is the above feasible? If so are > >>> there > >>> examples to compare with and learn from doing something similar? > >>> Where (api/code) would I start looking to accomplish the above? > > >>> Any tips to get me going would be much appreciated. > > >> easiest approach is to use multiple sessions, multiple engines. > >> Your > >> app would need to know which engine it wants to talk to, and binds a > >> session to that engine. Binding is described here: > >> http://www.sqlalchemy.org/docs/04/session.html#unitofwork_getting_bin > >> ... > > > 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). > > > In other words I'd like to have a handle to, say, a user object, and > > do reads/updates to it with the programmer using this object not > > caring about how the work gets done. So for instance I select a > > number of user objects that come from the local database. Later I > > update a field on one of these and the update takes place on the > > master directly. > > > Is that weird? Doable? Unfortunately this is the environment I need > > to get this working with. > > > As a side note, we manage this difference by hand now, it's really > > annoying which is why I'd love to abstract it away. > > > thanks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
