Mike- Thanks a TON. This is really helping to clarify things.
On Mar 6, 12:21 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > the impression I'm getting here is that the five database connections > are all talking to the same database, just with different > permissions. Is that the case ? Essentially, yes. This is the case for 3 of the connections. The other two are on different servers, but they could be on the same. > If so, it seems like this would be > highly dependent on what you're trying to achieve. Under what > circumstances do you need to talk to one particular database and not > another ? My answers below are based on this assumption but I'm not > sure if I'm understanding correctly. Variety of reasons: - i'm porting an app off straight-python and mod-perl. currently we're in a cluster where the read and write are on the same cluster. the read is off replicated and we get to ignore transactions, the write is on master and transactional. the table defs are 'the same', the db is 'the same'... however different portions of the application will use different db connects to maintain this partitioning. > An > application that switches between database connections which all > correspond to the same set of Table objects does not want to rely upon > engine-bound metadata and instead would use explicit engine access (or > would allow the ORM Session to handle it, if the ORM is being used). That sounds about right. > If I'm understanding your case correctly you'd probably want to have > five different session configurations each mapped to an engine, and > each Session would be a regular single-engine session. This based on > the assumption that a single connection stereotype can access all > tables. That is exactly it. I've really dumbed down and oversimplified the situation to get my point across. At no time will i be joining/ mapping information from one connection/session to another. I can't see the need for any sort of simultaneous usage, but I could be wrong... I might keep the 'session database' open while i'm working on the read/writes. > the session-connected-to-multiple-engines case is used in two specific > circumstances - when you have your data partitioned "vertically" > across multiple databases, meaning different tables exist only in one > database or another, and you'd like the Session to "transparently" > handle this divergence, or when you have partitioned your data > "horizontally", which means subsets of rows for a particular table are > stored in that same table as represented across multiple databases > (and again you'd like the Session to handle it). Both scenarios > present limitations that are not present when dealing with tables that > are all present in a single database. If in your case, all tables > are accessible via one connection, neither of these scenarios apply. no that sounds about it. I try to keep my partitioning on the db level whenever possible. So my result is this: - I already have 5 engines. - I currently have 1 Metadata. I could push this to 5. In my instance, it doesn't seem to matter. - I should have 5 Session What has really tripped me up , is the way the orm.mapper and sa.Table work with one another in this. I'm going to have to play with this a bit more... Some config is stored in MetaData and others in the Model Class definitions , so depending on whether i use 1 or 5 metadata items I'll have to do a convoluted mess to get the multiple metadata's configured right with sa.Table and orm.mapper ( because of storing the table def per connection, checking for it, and mapping it). If that sounds confusing, thats because I'm half lost on this still. But I think i can figure something out today. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
