using a temporary session is still problematic. because the lazy loading function needs to know how to create one. in many cases, thats easy, its just create_session(), but as we know in many other cases, its not, if the session needs to bind to an engine, or if it binds to muliple engines, etc. i would like to keep all mapper functionality completely independent of whether or not you are using Tables bound to Engines or Sessions bound to Engines; the simplistic version of this idea would require engine-bound tables.
im not thrilled about the alternatives, which would be a). lazy load functions that have to reference the engines used to create the session in the first place (increases latency, memory usage, impacts pickle-ness of objects, makes great big assumptions about create_session()), and b). it only works if the Mapper has a contexual session, which means it doenst work in all cases, and adds the latency of locating all lazy loaded objects and their children so that they can be surgically removed from the contexual session after they are loaded. in any case it seems like it forces SA to use some real guesswork/ assumption making/works-but-then-mysteriously-breaks-in-certain- configs to make this happen, whereas the hibernate restriction of, "you have to put your object back into a session somewhere for your lazy loaders to work again" is absolutely clear. is it so hard to just stick those objects into some auxilliary session ? On Jun 15, 2006, at 4:48 PM, dmiller wrote: > > On Jun 15, 2006, at 4:17 PM, Michael Bayer wrote: > >> all loading of objects has to be in the context of a Session. what >> session should the newly lazy-loaded objects be part of if the >> parent object is not in a session ? maybe just a temporary one and >> theyre immediately expunged ? the one associated with the mapper's >> contextual session if any ? > > I vote to have them loaded by a temporary session and immediately > expunged (like you suggested). This was something I hated about > Hibernate: once a session was closed objects loaded by that session > could no longer load related objects (Hibernate would throw an > exception if you tried it) unless they were merged into another > session. I think it is useful to be able to load related objects > outside the context of a session. This is very handy for lazily > loaded support data. The implication is that objects loaded in this > manner will never be saved automatically if they are changed. They > would have to be manually merged back into another session to be > saved/updated. The only downside I see to this behavior would be for > people who clear the session and then go on using the objects loaded > before the clear(); they may assume that those objects will be saved/ > updated on the next session.flush()... > > I guess the alternative for my hypothetical use case would be to use > a separate long-lived session for for support data and never clear > that session until all needed data is loaded. It may be nice to have > a warning about loading items on objects not associated with a > session... Now I'm not sure what I think. > > What do you think? > > ~ Daniel > > >> >> this definitely didnt do the right thing in 0.1.7, im sure it just >> loaded the child objects into the current thread's session. >> >> On Jun 15, 2006, at 4:15 PM, dmiller wrote: >> >>> I finally got the chance to upgrade my application to use SA 0.2. >>> Yay!! >>> >>> However, I have found a regression. After a session is cleared >>> objects loaded by that session can no longer load related objects. >>> Example: >>> >>>>>> s = create_session() >>>>>> user = s.get(User, 8) >>>>>> s.clear() >>>>>> user.addresses >>> [] >>> >>> The user should actually have 3 addresses, but since the session >>> was cleared the user object is not associated with a session and >>> cannot load its addresses. Is this a bug or did something change >>> that requires objects to be disassociated from their session when >>> the session is cleared? A test is attached. >>> >>> ~ Daniel >>> >>> >>> <session.py> >>> _______________________________________________ >>> Sqlalchemy-users mailing list >>> Sqlalchemy-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users >> > > > > _______________________________________________ > Sqlalchemy-users mailing list > Sqlalchemy-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
