On May 30, 2007, at 12:24 PM, Paul Johnston wrote:
> > Hi, > > For me, multiple database access already works fine - I have different > model classes that correspond to different database. In my scenario I > have my main database, plus other databases (just one so far) I > need for > particular operations. > > I'd be cautious about the clustering layer. It will work fine when > everything succeeds, but if there is a failure on one database they'll > get out of sync. Potentially you could take further steps to deal with > this, but databases' built-in clustering has generally got a lot of > magic to cope with such scenarios, and I don't think you could hope to > emulate it all. what everyone wants to do is (well, at least two people so far), is to take a range of values and distribute them among database clusters based on the data contained. i.e. all A-E entries go in database 1, F-H go in database 2, etc. im not familiar with any way to do that with the typical clustering software available for postgres or mysql. anyway, id just be building the "rules" part of this, and its up to the developer to make the best "rules" for their situation. the folks who ask for this already understand that theyll lose a lot of expressiveness with schemes that are distributing data based on individual row data. table-based rules should be pretty easy though...i.e. "if INSERT and tableX, send to DB #2"..."if SELECT and FROM contains tableY, pull from DB #1". > > I did come across one other pattern for multiple db access, which I'll > try to explain. In the environment, there are session and state > databases. The session database holds longer-lifed information, and > state short lifed. To minimise database access we envisaged a kind of > copy-on-write situation. In general, you would load an object from > session. If you only read from the object it stays in session. > However, > if you write to it, it is then saved in the state database. Writes to > the session database are only done when the app specifically > requests that. yeah, thats the other one that comes up. > > My reckoning is that's a fairly off-beat scenario (having just one > database would be much easier!) and is pretty low priority. I think it is kind of low priority. but the whole twitter debacle makes it slightly more urgent. those guys basically needed activerecord to do this (dish out SQL to multiple databases at the ORM level). Someone ultimately made some kind of patch for activerecord that achieves it. i have a feeling that whatever that patch is, is likely the same thing as just setting "bind_to" on your session in SA, though. but i really do want to have a response for people when this request comes up, and i definitely want to stop people from trying to add hooks into the ORM for it...adding the ORM hooks is where people naturally go first, since thats where the use cases are most tangible. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
