openerp-expert-framework team mailing list archive

[Alexandre Fayolle <alexandre.fayolle@xxxxxxxxxxxxxx>]

On 16/04/2012 11:00, Valentin LAB wrote:
>
> Ability to call record method on a set of records
> -------------------------------------------------
>
> We could question why this had to be done:
>
> - shorcuts ? It's maybe thought as convenient way to be able to call
>   the method on all the elements ?
> - performance ? This allows some optimisation that wouldn't be possible.
>
> Let me get in to this:
>
> shortcuts:
>
>   Calling a method on each record is no more than an automatic
>   classical "map" on record list. Besides the implementation of this
>   method is very often using a "for". The new API will remove the
>   "for". Very well, but why even keep this functionality ?
>
>   Let
>
>     >>> record_set = RecordSet(from_ids=[1, 2, 3])
>
>   Then, in the API proposal:
>
>     >>> result_set = record_set.method(args)
>
>   is equivalent to :
>
>     >>> result_set = [r.method(args) for r in record_set]
>
>   Why not use this last form when needed ? It's not that much longer...
>
>   Removing in the general case the possibility to call directly
>   methods on record_set has these advantage:
>
>   - it removes a specificity of openerp ORM, so it's API is easier
>     to grasp.
>   - it simplifies the implementation of the method (which should be
>     defined in Record class)
>   - less magic (and code) in the API implementation.
>
> performance:
>
>   It is true that in some rare case, you could get some performance
>   benefit by avoiding a complete loop. If this is of some importance, I
>   would suggest then to add optional API sugar for this case. (In this
>   case, the @multiple decorator in front of a method of Record object
>   would make some sense).
>
>


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 :

* the API must provide a way to report the exception, possibly noting
the ID of the record which generated it
* 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
* the API must provide a way of returning the values for the calls which
succeeded

Granted most of the time, no exception will happen, but "Errors should
never pass silently" (Zen of Python), so we must provide a clean way of
handling them. A possible way is to provide an error handling function
for such "vectorized" calls which will be called when an exception
occurs. The return value of that function could be used in the return
value of the recordset method call. If the error handler raises an
exception, then the recordset method call will raise it in turn.

Opinions?

-- 
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