sqlalchemy objects always log change events when things are modified.
when i need a "throwaway" version of an object I often use a separate
class for that, sometimes just a vanilla "object" subclass that I set
attributes on, i.e.
class Lightweight(object):
def __init__(self, **kw):
self.__dict__.update(kw)
@property
def lightweight(self):
return Lightweight(id=self.id, name=self.name,
attr1=self.attr1.lightweight)
the lightweight attribute above can be automated in different ways too so
that individual versions of the method aren't needed.
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
-~----------~----~----~----~------~----~------~--~---
