openerp-expert-framework team mailing list archive

[Parthiv Patel <parthivgls@xxxxxxxxx>]

+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=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á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/%7Eopenerp-expert-framework>
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework<https://launchpad.net/%7Eopenerp-expert-framework>
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Thanks & Regards,
Parthiv Patel