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