Marcin Krol wrote: > >> if you're looking for state between requests you can use an HTTP session >> for that > > *SMACK* forehead... Right.. Mental block.. > >>and "lightweight" objects are great for those since they are >> easily serializable and use minimal space. > >> Im a little confused, did you originally intend to persist state in the >> database between requests ? > > Well sort of - I wanted to store the 'throwaway' object in db, I didn't > think of using http session for that purpose. > >>you said you didn't want to call "commit" ? > > I don't want to call commit on original object until user presses Save.
OK. why not associate a "state" column or object with the objects so that you can differentiate between "saved" and "pending" ? > >> >> >>> Regards, >>> mk >>> >>> >>>> Marcin Krol wrote: >>>>> a...@svilendobrev.com 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 sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
