i think i found something... i am doing testing about these links and nodes. For each testcase i have one constant set of nodes, and then trying different scenarios with various combination of links. Each scenario creates all database stuff a new - db, metadata, mappers, session - and after testing destroys it all (session.close, clearmappers, drop_all, dispose).
because i am using same set of objects for many such scenarios, it happened that they keep _instance_key's on them, as noone deletes these. Hence first scenario will save Link1 with Node1 and Node2, but second scenario with Link2 and Node1 / Node2 will not save Node1 /Node2 as they already have _instance_key on them (from previous scenario / database ) and as of session.py are considered saved... and sooner or later mistakes got accumulated and even _session_ids are not cleaned, because certain objects are considered already-saved, i.e. not subjects of current session. All this is ok if i make db/metadata only once for a set of objects, still i would like to be able to drop_everything and start a new without side effects / leftovers. Any SA way to remove these _instance_key identity-mapping keys from the objects? That is, in my case, lifetime of objects is much longer that lifetime of all database-and-related stuff - and seems this is not expected pattern of usage. svil > > g'day > > > > i have Links, pointing to Nodes. > > > > Adding just Links to session + flush() works as expected - both > > Links and Nodes got saved. > > > > Doing session.close() although does not always detach all related > > objects, i.e. sometimes some Nodes stay with _session_id on them > > after session is long gone. > > > > "for x in mysession: print x" does not print those objects, i.e. > > they are not explicitly in the session. > > > > Is this some intended behaviour, and is there some way to clear > > these "cascaded" objects too? > > i think you should create a test case. also start poking around > the source code on this one, Session.clear()/close() are pretty > simple, and they shouldnt have to deal with cascading anything. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
