On Sat, Sep 10, 2011 at 4:54 AM, P. Christeas <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
