On Tue, 18 Jul 2006 05:36:31 -0700, Yuan HOng <[EMAIL PROTECTED]> wrote:
> 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. the real question, i think is why use the sa mapping layer at all in favor of the simpler layers in sa.exts that don't deal with session and dependency management at all, considering that you actually don't want transactional behavior, or alternatively if the sa mapping layer has desireable features, restructure the application as a set of small transactions corresponding to the transactionally independent items. fwiw, i agree that receiving/access to the offending object has value with some caveats, and that sa by default should do better on error then maintaining an uncommitable session state after an explicit txn operation. re caveats, if sa (afaicr) has abdicated object consistency checks, its the application's responsiblity, and deferring to database checks is a last resort not an app useable failure mode. -kapil ------------------------------------------------------------------------- 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
