On Jun 18, 2009, at 4:27 PM, Catherine Devlin wrote:
> > I'm building a complex ETL tool with SQLAlchemy that will sometimes > need to let the user "preview" a changed record - not actually carry > out the update, just find out which fields would be changed, and to > what values. I'm having trouble figuring out a good way to do it. > > Is there a way to get a sort of preview of an update - get information > about what updates are pending for the next flush, or get a flush to > report back its changes without actually performing it? you can get most of this stuff from the session without any flush occurring. at the object level are the "new", "dirty", and "deleted" collections on Session. At the attribute level the attributes.get_history() method will illustrate the full changes made since the last flush on an individual object attribute. get_history() should be in the API docs. what you can't get without flushing are newly generated primary key identifiers, server side defaults that havent fired off, and the results of cascades like delete or on update cascades. however if this does what you need this is definitely the best way to go as it doesnt require issuing a flush() which then has to be "rolled back" internally. > One approach would be to set echo to True, let the user see the echo, > then roll back the transaction, but there are a couple reasons I don't > think that will work for me. I don't want to make the user mentally > parse SQL statements; I'd like to get a dict of the pending changes > and write my own code to display them attractively, instead. Anyway, > I'm having trouble getting echo to work on this app. (The whole thing > is part of a TurboGears project, and my echoes aren't showing up, > probably because of something I don't understand about the SQLAlchemy > logging configuration.) If you went down this road, use a ConnectionProxy to capture all the SQL expressions as they are emitted. this is also in the API docs. The unit tests use a custom proxy to "capturing" SQL and expressions various operations, using a decorator to enable/disable the capturing. you can capture the SQL expression constructs directly where you'll have access to all the Table objects and bind params and you can display it in any way suitable. Depending on your needs I'd use one of the above approaches and I would not recommend instrumenting any of the ORM internals. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
