+1 for search_read and search_browse. It must be added in v6.
On Fri, Sep 17, 2010 at 8:36 PM, "Borja López Soilán (Pexego)" < [email protected]> wrote: > Hi guys, I simply think that both optimizations (search_read + > search_browse) should go into 6.0. > > My thoughts: > > - We haven't still released RC1, so the feature-list shouldn't be > hard-freeze yet. > > - They are "*one small step for a *developer, *one giant leap for the > *community". > Those two small improvements to the ORM may be used to greatly improve > the performance on custom modules yet to be developed. OpenObject as a > framework would benefit a lot from this! > > - Both changes are so small and independent that they hardly affect > anything. > > - We don't need to apply this optimization on the current addons yet, > just the framework. We may just use them on the new code (future > extra-addons, localization modules) that won't be freeze yet. So it is not > risky at all. > > - The GTK client could easily make use of these methods to optimize > its performance on high latency networks. > This wouldn't require to touch any "business code", so it should be > pretty straightforward (one day, couple of days?), I don't see why not to > implement it just before RC1. > > > Raphaël Valyi wrote: > > Hello xrg, > > well, I don't understand why you won't package that search_read OpenERP > v6 (at least our naive version if you are unsure about your implementation). > It doesn't matter at all how search_read is implemented in a first approach: > in our test, even if search_read simply calls search and then read, on the > client side, even on localhost or local network it's already nearly 2x > faster, just because it avoids to pass twice in the Python HTTP layers both > in the client and the server. Of course with latency (like Saas server), > then it's even closer to twice as fast. Aren't you folks at OpenERP S.A. not > interested in the Saas? > > Isn't version management all about API management? Isn't it all about > packaging a stable API in a release and then let modules use that API during > the release life? > > Then what is the reason you don't throw that method in, so that, during > the v6 life, modules and clients could eventually use that API, especially > to reach better speed. > In what does it impact the version management? Where is the hard work here? > > Again, yes, we will need ORM optimizations in the future. But what we are > talking about here is much simpler and has way more impact: if your network > has a 0.2 sec latency because your server is on an other continent, then > having such a method might often result the GTK client have requests in > something 1 sec instead of 1.2 sec, this will often bring something like 20% > faster for 3 lines of search_read code, what is the big deal? > > Sorry, I simply don't understand that stance. Could you explain us? > > > Raphaël Valyi > Founder and ERP Consultant > +55 21 3010 9965 > http://www.akretion.com > > <http://www.akretion.com.br/> > > > > 2010/9/17 P. Christeas <[email protected]> > >> Hi, >> I've been following your tweets about the search_read method. >> You may have seen that I had implemented that back in June for the >> browse() >> method (but wanted to show that it was possible): >> http://git.hellug.gr/?p=xrg/openobject-server;a=commit;h=a9fb6a76eb6db33fc >> >> yes, not only me, but other people here have thought about some >> optimizations >> that we could put into the ORM. I'll be following your progress, but >> please do >> so yourself: it should worth trying my "trunk-pg84" branch and see how it >> performs. >> >> I'd also like to ask you /not/ to expect API changes for v6.0 . We are >> trying >> hard here to "close" the version and make a release. Then, we could >> evaluate >> all the patches (mine are sitting in a queue, too) and put the >> improvements in >> for v6.+ . >> >> >> > > -- > Borja López soilá[email protected] > > Pexego Sistemas Informáticos S.L. > Avenida de Magoi 66 - 27002 Lugo (España) > Tel./Fax 982801517http://www.pexego.es > > > AVISO LEGAL - CLÁUSULA DE PRIVACIDAD > Este mensaje se dirige exclusivamente a su destinatario y puede contener > información privilegiada o confidencial. Si no es usted el destinatario > indicado, queda informado de que la utilización, divulgación y/o copia sin > autorización está prohibida en virtud de la legislación vigente. Si ha > recibido este mensaje por error, le rogamos que nos lo comunique > inmediatamente por esta misma vía y proceda a su destrucción. > > > _______________________________________________ > Mailing list: > https://launchpad.net/~openerp-expert-framework<https://launchpad.net/%7Eopenerp-expert-framework> > Post to : [email protected] > Unsubscribe : > https://launchpad.net/~openerp-expert-framework<https://launchpad.net/%7Eopenerp-expert-framework> > More help : https://help.launchpad.net/ListHelp > > -- Thanks & Regards, Parthiv Patel
_______________________________________________ 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
