Michael Bayer wrote:
> Kent wrote:
>> There might be a communication problem, which an example could help
>> clarify.
>>
>> I'm constrained by a legacy database that I have no control over
>> changing.  When an order is changed, I need to calculate the change in
>> volume (or points) so I can update a table that records this
>> information.
>>
>> Here is an example of a method you might want to run on an the
>> original, unchanged object (Order, in this case):
>> =================================================================
>> def calc_points(self):
>>     return sum(l.product.points * l.qtyordered for l in
>> self.orderdetails if l.product.points is not None)
>> =================================================================
>>
>> Notice that this calculation relies on several relations:
>> orderdetails, and orderdetails[].product
>>
>> From an MVC view point, my argument is that certainly this business
>> logic *should* reside in the Order class.  That is to say, "an Order
>> should know how to calculate its own volume".
>>
>> Unfortunately, this is not a matter of two or three *fields* that I
>> can easily extract from attributes.get_history().  This computation,
>> again, relies on several relations.
>>
>> Any further insight or advice?
>

also in case this is not apparent, this is exactly the kind of thing I do
with SessionExtensions.   For example if you look at
examples/versioning/history_meta.py in the distribution you'd see exactly
this technique using SessionExtension.before_flush() to create new
"version" entries for objects being modified or deleted.   Here's another
example from a Pycon tutorial in 2009:
http://bitbucket.org/zzzeek/pycon2009/src/tip/chap5/sessionextension.py -
this one modifies a "count" attribute on a parent table in response to
changes in a child collection, using after_flush().

we've hopefully implemented enough hooks into mapper and session to allow
any possible change-based operation.  there should be no need add esoteric
hacks into methods like merge().




-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.

Reply via email to