there are features meant to deal with this cleanly but they are a little glitchy right now. one is the merge() method that can transfer the state of an instance to another session. it doesnt really work to spec although you can play with it, theres a ticket to finish it up for real. the other would be that you could remove the various "save" cascade rules from your relations() so that child instances wouldnt necessarily show up in the session automatically....although im not sure how well that works in practice (also theres a ticket to try to work out test cases for that). also, if i added the "flush" cascade that would be another way that you could use the instance-specific flush() and have it find the child instances.
On Oct 25, 2006, at 2:57 PM, Rick S. wrote: > > Thanks!, Michael. That did work. > > When I solved one problem I created another. I guess it didn't help > that I did not heed the warning to be careful about explict flushes. > Not sure if this makes any sense but here is what I was trying to do: > > # mypythonscript.py > import myobjects > > # myobjects is my API that handles the connection/session/query > objects > # so that mypythonscript can use persistent objects but not care about > # the database back-end. > > # Thing1 and Thing2 are decorator classes containing SA objects. > thing1= myobjects.Obj1(name = 'thing1') > thing2 = myobjects.Obj2(name = 'thing2') > fish = myobjects.Obj3(name = 'gold'') > > thing1.A = "it's fun to have fun" > thing2.B = "but you have to know how" > fish.refill() > fish.save() # save and flush the internal FishTable object > > if momhome: > del(thing1); del(thing2) # for example > else: > thing1.save(); thing2.save() > > # If I use a general flush(), thing2 and thing2 were saved along with > # the fish...before I knew that I would need to get rid of them. > > # And, I don't want to do an API level flush at the end, e.g. > SaveAllOjects(). > # If the script fails, nothing is saved. > > So, I am looking for object independence. Sessions per instance makes > the objects in my library too indepedent. That is, I can't mix > 'related' objects that came from different sessions. A global session > in the library means I need to use explict flushes so that the the > script writer can control the order in which they save objects. Maybe > I'll take another look at transactions. But that may be a path to > madness. Hmm, back to the drawing board to find the third way. > > Thanks again, > Rick > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
