Kent Bower wrote: > It is helpful to know what SQLA was designed for. > > Also, you may be interested to know of our project as we are apparently > stretching SQLA's use case/design. We are implementing a RESTful web > app (using TurboGears) on an already existent legacy database. Since > our webservice calls (and TurboGears' in general, I believe) are > completely state-less, I think that precludes my being able to harness > "descriptors, custom collections, and/or AttributeListeners, and to > trigger the desired calculations before things change" because I'm just > handed the 'new' version of the object. > This is precisely why so much of my attention has been on merge() > because it, for the most part, works that out magically.
If you are using merge(), and you're trying to use it to figure out "what's changed", that implies that you are starting with a business object containing the "old" data and are populating it with the "new" data. Custom collection classes configured on relationship() and AttributeListeners on any attribute are both invoked during the merge() process (but external descriptors notably are not). merge() is nothing more than a hierarchical attribute-copying procedure which can be implemented externally. The only advantages merge() itself offers are the optimized "load=False" option which you aren't using here, support for objects that aren't hashable on identity (a rare use case), and overall a slightly more "inlined" approach that removes a small amount of public method overhead. You also should be able to even recreate the "_original" object from attribute history before a flush occurs. This is what the "versioned" example is doing for scalar attributes. -- 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.
