On 7/18/06, Charles Duffy <[EMAIL PROTECTED]> wrote:
Yuan HOng wrote: > One possibility is to clear the session cache, which however would > mean other valid changes would also be clear out and got lost. > Therefore I would like SA to inform the application which is the > object that caused the current SQL exception and then remove the > specific object from the session so that other changes would get > committed to database.I would object very much to that behavior -- if one part of a transaction fails, the whole thing should fail. If you don't want a set of changes to fail together, you shouldn't have them in the same transaction. If you don't want that behavior, I suppose that the groups that should fail together could be separated from each other using nested transactions, or you could keep the outer transaction separate.
Thanks for the comments. Let me explain my situation. I have an application with SA for product catalog management. The user can select products from the database, which the application then displays in a grid. Then the user can make modifications to the products. And after they are finished, they click an update button, which calls session.flush() to save all the changes they made to various products into the database. Say the user has modified dozens of products, and in one of them she has made an error, which is caught by the database checking routines, leading to an SQL exception. Showing the traceback to the user is meaningless. Except for parsing the SQLError as you mentioned, there is no easy to tell the user which product has caused the error. The transaction is not a problem here, since the products are independent of each other. Even if all modifications are wrapped in one transaction, I still have to point the user to the product which caused error. That's why I would like to receive the offending object itself as an argument to the exception so that I can highlight the product for user correction.
A SQLError already includes the generated SQL and bind parameters for whatever it was that failed, which (with, admittedly, some ugliness) can be used to identify the object in question. Passing in the updated object looks like it could be reasonable, though -- if I were implementing this I would perhaps just have Mapper.save_obj() modify exceptions as they bubble up past it. Perhaps Michael could comment as to whether I'm on the wrong track here? ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-- Hong Yuan 大管家网上建材超市 装修装潢建材一站式购物 http://www.homemaster.cn
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
