On Tue, 2006-07-18 at 09:32, Michael Bayer wrote: > On Jul 18, 2006, at 9:52 AM, Charles Duffy wrote: > > > 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. > > obviously we're not having SA do anything with the session if a flush > () fails; that would be up to a programmer to define whatever error- > handling action should occur at that point. > > with regards to wrapping the exceptions, it would work within > save_obj and delete_obj for now, although there was the notion that > those methods would also work in "batch mode", which is what they did > originally and would prevent knowing which specific object caused the > error. having this new functionality means we can't switch batch > mode back on again. > > similarly with many-to-many operations, those updates/inserts are > done in batch mode. > > it seems like the desire here is an automated system of removing > "bad" objects from a session; i disagree with that functionality as I > think if "bad" objects are getting into the session, and the > exception raised is not a concurrency exception, thats an application > bug which should be fixed; i.e. its not just a "oh lets remove the > offending object and try again" situation. > > id rather know what the specific error we're talking about is, and > seeing if theres a way we can just put an extra assertion in the flush > () operation beforehand if possible. > > if we are talking about some kind of graphical application thats > allowing end-users to throw whatever invalid states they want into a > session, then that graphical application needs to take more steps > beforehand to prevent invalid data from going into the session.
I agree that this is perhaps more of an application issue however there is some logic that supports the idea that across multiple applications the business logic should go into the database. What I interpret him asking for is basically the effect of autocommit. Where each interaction with the database takes affect immediately, not as part of a unit-of-work. What I suspect is the problem is that starting the session flush, it runs down the set of objects making changes. Then trips over one object that fails and stops. How to identify that object to remove it from the list of updates to be made and then re-initiate the flush so that the remaining objects have their changes propagated? This is a use case where transactions are not appropriate. HTH, William. ------------------------------------------------------------------------- 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
