A Dissabte, 10 de març de 2012 14:52:07, Cédric Krier va escriure: > On 10/03/12 13:08 +0100, Albert Cervera i Areny wrote: > > In 'stock.move' there's the product_type constraint (doesn't accept > > services) but when it happens it won't tell you which is the offending > > product and move. > > > > In 'account.move' you cannot post an unbalanced move, but you don't know > > which one it is. On the other hand, if you try to modify a posted one, > > you *do* get the appropriate message telling you which is the offending > > move you're trying to modify. > > > > Those things are not very important when you're operating on a single > > stock move or a single account move, of course, but it is when other > > processes operate on them (such as a shippment) or there's an action to > > apply to a set of them (such as posting a set of account moves). > > > > Fixing the cases when one uses 'raise_user_exception' is quite simple > > because you simply have to improve the message and that's it. > > > > When it comes to simple (python) _constraints, what we do is raise a user > > exception instead of returning False because it's the only way showing > > enough information. I comment in one of my latest patches tells me to > > return False, but I think we should find a solution for this if we do > > not want to raise exceptions. I must say, I think it is a valid solution > > to raise an exception and we could even change the _constraints > > behaviour to simply expect the programmer to raise the exception instead > > of acting on the result of the function. > > I agree, it is an idea in the pipeline since sometimes. > But I think it should be changed globaly.
Why should it be changed globally. If we said that properties can be changed one at a time, I don't see why we can't commit checks that raise exceptions while existing ones still return False. > > The main issue is for _sql_constraints. We currently do not have a > > solution for that, even if it would be nice to know which is the record > > that raises the exception. > > Normally it should have not many _sql_constraints because they are > impossible to customize. And the client should prevent them and so if > user see it then it must be because there is a bug in the code. -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
