With regard to the nested transaction suggestion, I was hoping that this
would allow an inner transaction to be rolled back after encountering an
error, such that the outer transaction could continue (which I
understand to be the behavior you're wanting, right?). Also, by
segmenting the changes into a different inner transaction per product,
one could tell which product an error was with regard to by looking at
which inner transaction failed. After some research, it looks like a
failure in the inner transaction may kill the outer transaction as well,
such that this suggestion isn't actually a practicable way to (1)
isolate individual operations such that you can tell which one failed,
and (2) allow as many operations as possible to succeed. I might be
wrong about this -- if the inner transaction can be rolled back after
the error occurs, that would mean you could proceed with others -- but
I'd need to actually test it to see what the behavior is.
Anyhow, as I was saying, it looks like it should be possible to attach
the object to the exception in Mapper.save_obj() so you can find out
which object the issue is related to. The component of what you
suggested I have serious concerns about is having SQLAlchemy remove the
object which is causing the error from the session (and then commit the
rest), since committing anything in the presence of an error is
frequently a Bad Thing and is only reasonable behavior if explicitly
intended.
-------------------------------------------------------------------------
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
