openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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.+ .
>
>
> --
> Say NO to spam and viruses. Stop using Microsoft Windows!
>