On Thu, 2011-08-04 at 11:15 -0500, Matt Feifarek wrote: > On Thu, Aug 4, 2011 at 12:44 AM, Mike Orr <sluggos...@gmail.com> > wrote: > The transaction should fail when the update query is run, not > when it > commits. So you shouldn't set the 'authenticated' flag until > the query > finishes without error. > > > Good advice, but not possible in this case; I'm using ZODB... the > "query" is just "foo.bar = 7" and isn't *really* done 'till commit, at > which case the execution has left my code and is happening deep in the > guts of WSGI middleware. > > > I remember the .save() in the old Pylons session, and thought that > made sense to revive, too. > > > I kinda feel like there is still a larger question here, though... > using transaction manager, code that is executed in a view callable > doesn't *really* finish till after the users' function is over... so > there's no chance of cleaning up if the transaction fails.
Actually, there is: http://www.zodb.org/zodbbook/transactions.html#after-commit-hooks > I guess what is likely to happen is an exception, and in production, > that would lead to a blank 500 error, which is the right thing. But > because it's kinda unpredictable what has actually happened in the > view callable, it's hard to write safe code... which means that the > safe way is to manage ones own transactions when there is sensitive > code, which means that maybe transaction manager itself is not a good > fit? I hope not, because I like it. > > > We can fix session storage to be transaction aware; maybe some kind > soul will (maybe me)... but I can think of other dangerous code > inconsistencies... say a database-dependent security check is required > before a user is allowed to delete a file on the filesystem... we > can't make file io transaction aware, so it would be possible to > actually delete the file and have the database part fail. This might > be unlikely because why would you WRITE to the database for a security > check, but I'm working in the land of theory here. We actually can and do make file io transactional: http://docs.repoze.org/filesafe/ > The very nature of transactions says that when you do something, it > doesn't really happen 'till later. Surely we are not the first folks > to discuss the ramifications of this in computer science... and surely > there must be a pattern to make it work. I would assume it would be > all or nothing, kinda like twisted. If you're in on transactions, you > have to be ALL in. > > > Pyramid likes callback functions, maybe we need to have some here? > What if every view callable had three components, main, > success_callback, fail_callback. Perhaps a handler class could do > this? It would completely axe the nice view-callable metaphor that > pyramid has going for it... "just a nice function attached to HTTP". > And even so, as far as I know, when repoze.tm2 executes, pyramid is no > longer in charge, it's wsgi pipeline, so we couldn't get the execution > back anyway. > > > Ugh. Is there an actual problem here that can't be solved by either making sessions transactional or by after-commit? - C -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
