does this pre-empt the patch that you sent me for "Session-izing" the objectstore ? I havent gotten a chance to look at that yet.
question: does having each object maintain a reference to a unitofwork object impact its serializabilty (oh, i guess you mentioned that...)? that is a key goal, if we go forth with an idea like this there would have to be some indirection going on, such as attaching a hashkey or some identifying string to the object instead. this string is discarded upon import_instance. > - a given object cannot be associated with more than one unit of work > (is this a problem? are there use cases for associating an object > with more than one uow concurrently?) not concurrently, but the unit of work begin/commit pattern creates a second child unit of work. also, it is supported behavior that the current thread-local unit of work can be changed at any time. for this reason, I think associating objects with a unit of work would have to be done through some intermediary scope object, along the lines of your previous patch. It also might be nice to have this object attribute be optional if the regular scoped operation is desired (the default), and also might be nice to have the initial association of this object to a session be handled by some callable or other argument passed to the initial mapper() construction (or probably MapperExtension is the place for this to be). I would very much like to avoid adding arguments to every single mapper operation. In fact, you could probably construct this right now via a custom MapperExtension that decorates the initial creation of objects, and putting a special scoping object in objectstore.uow() (with perhaps those changes to ScopedRegistry). Just some things to think about, Im a little time-starved this week and havent gotten to play with this stuff yet. - mike dmiller wrote: > Proposal: > - allow a unit of work to be passed into mapper.get/select operations > (fallback on objectstore.uow if not provided) > > Implications: > - once an object is associated with a given uow any objects loaded > via relationships on that object will be loaded in the same uow > - each SA-managed object will retain a (weak?) reference to the unit > of work in which it was loaded > - a given object cannot be associated with more than one unit of work > (is this a problem? are there use cases for associating an object > with more than one uow concurrently?) > - an object's reference to a unit of work should be cleared if the > object is serialized (how are weakrefs handled with regard to > serialization?) > - it should be possible to "move" an object from one uow to another > (I believe this is already possible using import_instance. do all > related objects move as well? probably not. maybe the object's > relationships should be "cleared" so they are reloaded in the new uow > if called for) > > This proposal, if implemented, would allow the use of multiple > UnitOfWork objects concurrently. Currently, this is possible in a > very inflexible way: the global uow must be switched each time the > local context switches. > > Example use case: > A rich client app could load support data in a global uow to be used > in navigation controls, dropdown lists, etc. Then it could use one or > more different uow's for data that is being edited. Each uow could be > committed separately without affecting other uow's. > > I'd be willing to work on a patch (maybe a branch would make more > sense for this). Thoughts? > > ~ Daniel > > > On Feb 7, 2006, at 6:09 PM, Michael Bayer wrote: >> >> >> dmiller wrote: >>> 2. Switch the active UOW each time a window gains focus (error prone, >>> messy) >> >> Actually this is probably your best option. because, its not just >> passing >> the UOW to all explicit mapper operations, the UOW is used every >> time you >> set an attribute on an object or append/delete from a list attribute. >> >> If your "sessions" really do correspond with "window focus" then >> you would >> have to match them up that way. Just like the widgets on the screen >> correspond to the window, so the individual data objects they >> represent >> correspond to the UOW. I gather your object-modify and commit() >> operations are occuring within an event loop ? Maybe you could >> extend the >> event-loop system itself to always insure the correct UOW is >> selected ? >> >> - mike >> > > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Sqlalchemy-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
