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