id probably go with the temporary session idea. also session.merge() is not tested very much in 0.2. I didnt yet get into that "merges the changes from the detached objects to the attached ones" idea yet either, although the rewrite of the attributes package I just checked in may make that job easier (which also blows away HistoryArraySet in exchange for a simpler list object, btw)
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 >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users >> > _______________________________________________ Sqlalchemy-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
