openerp-expert-framework team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 04/16/2012 02:13 PM, Alexandre Fayolle wrote:
> Hello Olivier
> 
> Since you answered off-list, I'll do the same, but feel free to forward 
> my message to the mailing list if you feel it belongs there.

My bad, my answer was meant for the list, sorry about that!
Hope the quoted answer will be readable enough for anyone interested, otherwise
I'll forward the original answer.


> On lun. 16 avril 2012 13:03:59 CEST, Olivier Dony wrote:
>> On 04/16/2012 11:26 AM, Alexandre Fayolle wrote:
>>> Another point which should be clarified if the record_set.method(args)
>>> is implemented is the behaviour wrt exceptions. The behaviour of
>>> method(args) raising an exception for one of the ids of the recordset
>>> should be well defined, which seems a bit awkward :
>>
>> It must be very clear for the developer indeed, but there is perhaps not much
>> to invent here, the semantics are already quite established I think.
> 
> I'm sorry I'm such a newbie openerp-wise. The slides made absolutely no 
> mention of exception handling, and this is one of the points which 
> deserve a note in the API specification, imo. I'll study more the 
> existing behaviour. Also if the explicit looping is still available, 
> then of course it is not necessary to add complexity to the vectorized 
> API.

You're right, this is something that was overlooked in the slides because we
did not foresee any major change in it, but it is definitely an important API
concept to mention in the specs.


>>> * the API must clearly state whether it will try to call the method on
>>> remaining records after a call on a record has failed with an exception
>>> or not
>>
>> This has always been quite clear (I hope!): everything is happening within a
>> transaction and the transaction is aborted and rolled back immediately as a
>> whole. It is vital for an ERP framework to guarantee the proper fail-fast
>> handling of transactions everywhere... even when developers wish it was working
>> otherwise ;-)
> 
> That's fine when the method is doing pure in-DB transactional stuff, 
> but can get awkward when the status is mixed (such as with method both 
> affecting DB state and the outside world)

Certainly, when you're mixing transactions with non-transactional things (e.g.
emails) you need to decide how you want to maintain transactional consistency
and data integrity. This is probably more of a case-by-case choice, though.
Common approaches could be to postpone the external calls to the last step of
the transaction (when the rest is validated and ready to commit), or wrap it in
a transactional layer (like our email queue), etc.


>> Practically speaking, if your business code needs to call a method on a
>> record_set, it should either:
>> - call it on the whole record_set and let any error propagate upstream
>> untouched - presumably something unexpected happened and the original caller
>> needs to be notified
>> - or switch to a `for` + `try/except` approach in order to handle *expected*
>> downstream errors record-per-record (being careful to let *unexpected* errors
>> propagate)
>>
>> In both cases the semantics seem simple, clear and consistent, don't they?
> 
> Once the exception handling strategy is clearly worded, yes :-)
> 
> --
> Alexandre Fayolle
> Chef de Projet
> Tel : + 33 (0)4 79 26 57 92
> 
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac Cedex
> http://www.camptocamp.com
>