On Wed, Aug 3, 2011 at 1:12 PM, Chris McDonough <chr...@plope.com> wrote:
> > In fact, an argument could be made that if a transaction fails, the
> > entire contents of the view callable should not execute...
>
> We don't know whether the "transaction failed" until the view callable
> is called. The definition of a transaction "failing" is either an
> exception is raised by view code or the view response code is 4XX/5XX.
And by the time it fails, our view callable is finished (or has thrown an
exception), so we can't branch code based on failure.
But, back down to earth, doing something like setting a value in session
when there is a transaction failure could lead to inconsistent state. Say a
view callable is supposed to log someone in... but a database transaction
fails. Meanwhile, our view callable has turned on "authenticated" in the
session, but they didn't actually login successfully...
It might be far-fetched, but I found it already ;-) Thankfully, not a
security breach, just a bad UI message, but still...
What kind of strategies make sense in this situation? I suppose if one
separated "action" from "output" and did all the actions first (setting db
values, etc.) and then added a success callback that called output functions
("your setting was a success!")?
I also know that we can manually commit() transactions when it might be
important (login?)...
--
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.
