[Cubicweb] NativeSQLSource.doexec auto-rollback

Christophe de Vienne christophe at unlish.com
Tue Dec 30 18:31:30 CET 2014



Le 30/12/2014 18:24, aurélien campéas a écrit :
> 
> 

[...]

> 
> 
> After reception of an IntegrityError, you can be sure that the sql backend
> wiped the current transaction clean.
>  
> 

What? Why?

It does not seem logical to me at all. Am I totally mistaken?


>     >
>     >     - If an error occur at the sql level, it will be transmitted or
>     >       translated to a CW error, which is fine. But if the exception is
>     >       raised and handled in a higher level function, why do we make it a
>     >       critical error?
>     >
>     >     - Admitting that rolling-back automatically on errors is wanted in some
>     >       cases, how can it be considered 'critical'? The caller will receive
>     >       the original exception anyway, it is its job to decide if it is
>     >       critical or not.
>     >
>     >
>     >
>     >     So basically, I would like to propose 2 things:
>     >
>     >     - Remove the 'critical' logs, and change them into into 'debug', or
>     >       'info'.
>     >
>     >
>     > +1
> 
>     Ticket+patch: http://www.cubicweb.org/ticket/4801120
> 
>     I chose 'debug' and 'info' levels for the rollback and sql error logs.
>     I wonder if using 'warning' could make sense.
> 
> 
> Choosing warning would keep the information more visible.
> Integrity errors are rare events in general and we may want
> to keep them easily spottable in a log stream.

I will update the patch to use 'info' and 'warning' instead.


Christophe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20141230/516b27c8/attachment-0214.sig>


More information about the Cubicweb mailing list