openerp-expert-framework team mailing list archive

[Santiago Argüeso <santiago@xxxxxxxxx>]

+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)" <
> 
> borjals@xxxxxxxxx> 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 <p_christ@xxxxxx>
> > 
> >> 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ánborjals@xxxxxxxxx
> > 
> > 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     :
> > openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> > 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.