openerp-expert-framework team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

On Sat, Sep 10, 2011 at 4:54 AM, P. Christeas <xrg@xxxxxxxxx> wrote:
>
> [...]
> >    - yes, OpenERP is quite batch oriented and this is nice, but many
> > things, even on the server side are not batch oriented at all, mostly:
> >       - on_change that allways apply to one record and still un accross
> the
> >       browse loop bloat
> >       - workflows signals and actions
> These have to do with poor coding. When you are called like
> "on_change_foo(cr,
> uid, ids, args, context)" you are really expected to operate on all of
> 'ids',
> not only on the first one!


Sorry, but I would like to ensure you don't miss the current API design
issues, or else you might just fail to plan its correction over the next
releases. Yes, this is poor coding, but it's a the API level, not just the
implementation, let me explain: yes on_change eventually admit a list of ids
in their params, but:

   - on_change is expected to work even if the record isn't saved yet, so
   the ids param is almost never used. Even if it were used, that would mean
   the method should work both the the ids and on the values in case the
   records aren't saved, that would mean double coding, bad.
   - but mostly, the client API expect a "value" dictionary as the return of
   the on_change, not an array of values. Meaning, the current client API force
   the on_change not to be batch oriented.

So I hope you are now convinced that at least the workflow and he on_change
API totally miss the batch orientation of the OpenERP ORM.
So I think ideally, you end up (not for 6.1) building an ActiveRecord
abstraction (it can still retain a total compatibility with the batch
orientation, look OOOR API for instance), the same in the sever side or
client lib and you use an AciveRecord orientation in those methods, well
unless you refactor it heavily to become batch oriented too.
May be the solution would also be to split those methods into a non batch
oriented method that quickly call into batch oriented methods. At least that
would make a larger part of the codebase available to batch manipulation. At
the moment a huge part of the OpenERP logic is prisoner of those non batch
oriented slow on_change methods.


Regards.


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com






>
> > 4) Finally, about the transaction thing: yes, ...
> > One approach however I have been experimenting with OOOR was the
> following:
> > you could actually have on long pooling socket ...
>
> Well, all aproaches are considerable. The bottom line is, however, that the
> server will need a significant change, before it allows multiple RPC calls
> in
> the same db transaction. And then, more issues will emerge (keep my word
> for
> that).
> If you see the examples at "libclient", you will notice dummy little
> scripts
> that don't care about transactional safety. In "buildbot", these operations
> that need atomicity are moved to the server side[1] and done in a single
> RPC
> function. So far, avoided the big change.
>
>
> [1] once you code a few lines in the client library, it is easy to add the
> "(cr, uid.. " prologue to functions and move them to server side.
>
>
> --
> Say NO to spam and viruses. Stop using Microsoft Windows!
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>