the copy can be a dummy non-db-aware - if that is ok in your case there's yet another option; u can just go all over the original object, and on cancel do a rollback, and restore all changed stuff back by hand (eventualy looking at object-state's history). But this assumes short editing/single user.
if the editing session is really long, u need a "user transaction", that is a copy saved to the db etc. then later at ok, retrieved, removed and replacing the original object (or upgrading if u have versions). m2m relations are ok for copying; but they have caused me some leftovers when creating new objects then destroying them without save. one2many are the tricky ones - there's no "copy" as semantics, there's "move". AFAIK there's no a perfect solution for all cases; u have to decide which one is the least painful for your setup. On Wednesday 06 May 2009 18:00:33 Marcin Krol wrote: > [email protected] wrote: > > u'd better edit a new copy and on save copy all back into > > original then commit that one, on cancel abandon the new one (but > > beware of m2m relations if u have them). > > all else isn't safe/nice IMO. > > To make it specific, should I do smth like: > > 1. on beginning of edit, make a new instance of an object, then > copy all the attributes from the original object, save the 'under > editing' object > > 2. on user save, copy all the attributes from the 'under editing' > object one by one into the original object, expunge the 'under > editing' object, do session.save()? > > I'm not even sure this would be safe, as I indeed have many to many > relation, Reservation having many Hosts, with hosts being > added/removed in Reservation. > > So I would be moving or copying the Hosts collection from one > Reservation object to another Reservation object and back -- Mike, > is this safe? > > Regards, > mk > > > On Wednesday 06 May 2009 17:25:47 Marcin Krol wrote: > >> Hello, > >> > >> I would like to implement typical Save / Cancel dialog operating > >> on normal SQLA objects. > >> > >> For that purpose, the most convenient way is to make a shallow > >> copy of an object using copy.copy(obj), let the user edit this > >> object, and on user pressing OK in dialog replace it in SQLA, > >> e.g. expunge existing object and add the edited object as > >> replacement (and obviously drop the edited copy of object if > >> user pressed Cancel instead). > >> > >> The reason I'm trying to do this instead of just doing > >> session.commit() or session.close() on the changed object is > >> that editing in my app is pretty complicated and it is done > >> across many http requests, so I obviously need to save the state > >> of the object in between them. > >> > >> Are there any problems with such approach? Risks? Is this safe? > >> > >> There obviously have to be some issues, such as enforcing the > >> same PK in a new obj as in the old object, which is the first > >> issue that comes to my mind. > >> > >> > >> Regards, > >> mk > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
