u're talking about full replication... what's the possiblity of local-readonly DB to have different (older) data than that of the master? and how this should be tackled?
theoreticaly from what i get of the multi-sessions/engine approach, then your two sessions (one writeable:master, one readonly:local) may have different objects which represent/has to be one object? On Monday 09 June 2008 21:22:48 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_gettin > >g_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 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 -~----------~----~----~----~------~----~------~--~---
