Hi again Michael, > I only had a brief look. However, the changes are making the whole > thing more flexible than it was before, so I am sure your > "engine-switching" scheme can be used. The MetaData which holds your > tables can have its engine switched at any point, and the Session can > also have overriding functionality added to do wahtever kind of > translation might be desired. you can also maybe make a "clustered" > engine that manages mulitple connections; its pretty open-ended. you > should study the new code and see if you can come up with something.
I will do that. I'll reproduce here what we need in a more concise way to be easier to grasp (and keep an eye on). For client-side clustering we need to be able to have a single class, with a single mapper, associated to more than one connection. Not only globally at commit time (e.g. switching the whole engine), but also per-instance (selecting the connection). > i want to focus on getting 0.2 to work fully and stick it in the > trunk, and very importantly getting some basic docs down which is a > daunting task at the moment. if you cant come up with anything, ill > try to have a closer look at your desired implementation. Thank you very much. On my side I'll try to follow your changes and come up with something. -- Gustavo Niemeyer http://niemeyer.net ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
