> 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. > > >> Regards, >> mk >> >> >>> 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 -~----------~----~----~----~------~----~------~--~---
