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. 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
