Greetings! (long mail ahead, sorry, couldn't make it shorter :-)
I've just followed the "Transactions and Sessions, proposal #2" thread, and I'm quite excited about the changes that seem to be coming soon. I'd like to explain part of our usage case so that perhaps it may be considered while doing these changes, even because, as stated in the first mail in the thread, it's already being somewhat considered. As explained previously in a private mail to Michael, we're using SQLAlchemy in a "client-side database cluster". We have many tables that are common accross a set of database machines, and data pertaining to certain objects are handled by one of these databases. SQLAlchemy is already doing a job much better than all the other ORM engines that we've looked at. There are just a few things that we'd like to do which are currently hard with the current infrastructure, and will certainly become much easier with what's coming. One thing I haven't seen mentioned in the current purpose though, is the ability to bind a given object to a certain engine. Let me try to explain with a usage case, so that the problem becomes more obvious. We have a class SomeClass, which includes SomeClass.mapper. Using the changes being proposed it'd be possible to do something similar in essence to SomeClass.mapper.using(connection).select(), which is perfect to what we need. OTOH, that's one element in CRUD. The feature I'd like to propose for consideration is including the ability to have engine/connection-specific counterparts for the other three elements. I know that our usage case is not the most common case, and thus by no means I want to change the common workflow to support us. But it'd be great if some minor details could be introduced that at least would give us a chance to hook into SQLAlchemy, or to hack it to a minor extent, and get the support we need. We've already spent some time on SQLAlchemy trying to understand what would be needed for that support. One problem with the current implementation, from this point of view, is that it lacks a relation between instances and mappers/engines/connections/etc. The relation is established at commit time, and is established by looking into a registry which is using the object *type* as the key. As I said, that's totally fine for the usual cases, but trying to hook a runtime-specified engine into instances becomes a hard task, even because after that initial mapper lookup, the link with the object is lost, and thus the ability to tell the insert()/etc in many-to-many relations and the such that this object should be committed to a given engine. One thing that passed through my mind was adding support for a _instance_engine option, which would be optionally looked up to determine the engine to use for commit/delete. Using the proposed approach of SomeClass.mapper.using(connection).select() could perhaps set that attribute in the instance as well, since it's natural that an object is committed back to the engine that loaded it. Well, I guess that this mail is long enough already. I'll be glad to talk further about this, and would be delighted to see any kind of support towards this being introduced in SQLAlchemy, even if partial. If that's too off-track, I'll of course understand as well. Thanks for the huge effort being put in SQLAlchemy! -- 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
