+1 Borja, totally agree
On Viernes, 17 de Septiembre de 2010 18:38:14 Parthiv Patel escribió: > +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=a9fb6a76eb6db33 > >> fc > >> > >> 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/%7 > > Eopenerp-expert-framework> Post to : > > [email protected] > > Unsubscribe : > > https://launchpad.net/~openerp-expert-framework<https://launchpad.net/%7 > > Eopenerp-expert-framework> More help : > > https://help.launchpad.net/ListHelp -- 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 Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
