[ZPatterns] Catching mysql exceptions

[John Eikenberry]

Ok. Reorganized a bit to eliminate the sub-commit in the problem method.
Also just remembered TransactionAgents and re-reading its changelog I noticed
it claims to fix this problem. Have to take a look at that.

Just thought I'd let people know the problem is resolved.


John Eikenberry wrote:

> After some experimentation I've pretty much come to the conclusion that I
> need the sub-commits to get the level of control I need to handle the
> database errors appropriately. Though I'd like to be told I'm wrong. :)
> 
> On to the next question... I've getting an infinite loop in a skinscript. I
> think it has to do with the timing of the sub-commits, as one of the
> methods called in the skinscript makes a sub-commit. Its on "WHEN OBJECT
> CHANGED CALL" trigger. I'm thinking that sense the subtransaction which
> fired the trigger isn't yet complete (marking the trigger as having fired?)
> when it makes another subtransaction commit. I'm getting into a sort of
> infinite transaction recursion. Does this make sense? Thoughts?
> 
> Thanks.
> 
> 
> John Eikenberry wrote:
> 
> > We need to be able to catch exceptions raised by the MySQL database backend
> > in certain cases (eg. duplicate unique indexes). The current method is to
> > cause a sub-transaction commit and wrap it in the try:except: block. But
> > these explicit commits are causing other problems with our ZPatterns based
> > code.  Besides losing the advantages of ZPatterns transaction like
> > behaviour.
> 

-- 

John Eikenberry [jae@kavi.com]
______________________________________________________________
"A society that will trade a little liberty for a little order
 will deserve neither and lose both."
                                          --B. Franklin