Kent Bower wrote: > > Could I look it up in a separate session and then merge it into my main > session? Then, after that, merge the transient objects into my main > session? Would that get me closer? Ideally, I wouldn't want it to need > 2 trips to the database.
there's this implication here that you are getting these objects back from the DB and doing some kind of "compare" operation. Its true this isn't much different from doing a get() and then running your "compare". The only thing that's not there for that is the traversal, but that still confuses me - if merge() is deep inside of a traversal, and its on order.orderitems.foo.bar.bat and then you see a difference between the existing and new "bat" objects, aren't you then traversing all the way up to "order" to set some kind of flag ? i.e. it seems like no matter what, your system has some explicit traversal implemented, in this case moving upwards, but if you were to implement your own merge()-like function, it would be downwards moving. if the model of how you see this happening is really that you need to traverse your object deeply and record things in some central point as you do it, this is best accomplished by using a traversal that is separate from the internals of merge(). If there were a feature to be added to SQLAlchemy here, it would be a generic "traversal" algorithm that anyone can use to create their own travserse/ merge and/or copy functions, since the traversal along an object graph of mapped attributes is a standard thing (probably depth-first and breadth-first would be options). There are components of this traversal (the methods are called "cascade_iterator") already present but they haven't been packaged into a simple public-facing presentation. Ideally the internal prop.merge() methods would ride on top of this system too. Traversals like these I most prefer to present as iterators with some system of linking attribute-specific callables (i.e. visitors). That said, I don't think implementing your own merge()-like load-and-traverse is very difficult - which I say only because I don't have time to create an example for this right now. > > > On 4/29/2010 4:48 PM, Michael Bayer wrote: >> 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. > > -- 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.
