[Cubicweb] ValidationError and implicit rollbacks

Aurélien Campeas aurelien.campeas at logilab.fr
Thu Sep 30 17:04:49 CEST 2010


Le jeudi 30 septembre 2010 à 16:53 +0200, Sylvain Thénault a écrit :
> On 30 septembre 16:06, Aurélien Campeas wrote:
> > Le jeudi 30 septembre 2010 à 15:57 +0200, Adrien Di Mascio a écrit :
> > > Hi there,
> > > 
> > 
> > Hi,
> > 
> > > In CW 3.9, if a ValidationError is raised, the transaction is implicitly 
> > > rollbacked. As far as I understand, this is done to prevent any later 
> > > commit() (in the same transaction) from letting the database in an 
> > > inconsistent state.
> > 
> > hmm, it used to be that the commit/rollback, from the web front pov, was
> > done in application.publish (or something)
> > 
> > that is quite predictable & allows various ValidationError handling from
> > beneath
> 
> such as ?

collecting them for reporting purposes

>  
> > am i missing something ?
> 
> this has been introduced because currently, it may occur that a ValidationError
> is raised but the value has been saved in the database. The repository should
> not let a subsequent commit commiting the database with some integrity error 
> inside.

"user" code catching ValidationError do so with full responsibility; I
don't believe the _querier_ has a say in it

> 
> We already had such behaviour in case where Unauthorized is raised. It's now
> documented that it also happen on ValidationError. We also already had such
> mecanism in case of error during commit.
> 
> The other possibility is to do like regular DBMS does: no rollback is done,
> but the connection is left in a state where you can't do anything with it
> until you rollback. I don't think that would make anything better though.

regular DBMSes, fortunately, provide means to tell to defer constraint
checking with DEFERRED/DEFERRABLE stuff so as to allow a temporary
inconsistent state (when they do not provide this, it is a real PITA and
must be worked around as was recently discovered with sql server and
unique constraints)

the db MUST be consistent by the end of the transaction but there can be
no garantee before that

> 
> > > For the record, I've discovered this because I implemented a custom 
> > > EditController that catches ValidationError and is able to treat some of 
> > > them as part of the normal execution flow under certain conditions.
> > > 
> > > This post is here to inform some of you who, just like me, might have 
> > > skipped this new "feature". I wonder however if I hadn't prefered simply
> > > a non-commitable transaction (i.e. waiting for an explicit rollback()) 
> > > rather than an implicit one.
> > > 
> > > What do you think ?
> > 
> > Immediately & automatically (behind-our-back) rollbacking on
> > ValidationError is wrong (I think it breaks working customer code).
> 
> such as ?
> 
> 

excel import

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Ceci est une partie de message numériquement signée
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20100930/ab1a2aa5/attachment-0250.sig>


More information about the Cubicweb mailing list