openerp-expert-framework team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello Ferdinand,

I should say I agree very much
In OpenERP, if you do in some python method:
self.pool.get('product.product').bowse(cr, uid, 1)
self.pool.get('product.product').bowse(cr, uid, 1)
It will indeed issue the same SQL statement twice instead of reusing an ORM
cache. Such code looks stupid, but in fact, the way OpenERP modules work by
extending them each other, it happens a lot, when you do some for order in
self.browse(cr, uid, ids) and call super, well super will probably do the
same thing and re-browse + prefetch all the crap over again and again. I
should say I have been shocked when I discovered this as this is a very
basic feature many ORM have.

I heard many times OpenERP ORM is better because it does this or this over
over ORM X. But many times I'm sorry, the core team would better learn the
existing standards and see how they work well on such basic things. It's
acceptable not picking a standard when you can justify what you are doing
better, but unfortunately, sometimes I rather feel the standards were not
mastered before rejecting them in bloc; or not learnt after they went
better. (like the urban lend I hear again 1 month again that for instance
OpenERP ORM would be better than Rails ActiveRecord on the batch
orientation, which is now absolutely wrong since some 3 years ago and AREL
which does the job much better BTW). I don't negate that we have a few
specific things like the integrated right management thing, but I say such
basic caching features are a basic thing to have to be called an ORM today.

I think some Spanish guy (can't remember who sorry, may be Borja?) worked
on this caching thing a few years ago. May be time to give it a look again.
But of course, if cache is to be added, then the cache invalidation should
be implemented with a lot of care or nasty bugs will start to occur.

Also, an other main issue is that in fact OpenERP ORM is not too bad for
read access. But when it comes to writing, function fields are often
re-computed over and over in the same transaction and leading to poor
throughput performance (at Akretion we have many e-commerce customers with
a massive amount of transaction and we see the limits of the current ORM
implementation).

Anyway, I don't want to sound negative here as I'm aware of all the
improvements achieved year after year, it's just that this caching and
function field things are really hot performance bottlenecks today.


Regards,

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com




On Tue, Aug 14, 2012 at 7:13 PM, ferdinand <office@xxxxxxxxxx> wrote:

>  Hello!
>
> please see also my posts dated Aug 14th 2012
> http://www.openerp.com/forum/post111629.html
>
> Quote
>
> I just traced the SQL statements
> for every insert of a SO Line 43 (a prime number hence no carthesian
> product) identical selects are done.
> I could imagine that for every function field or for each on change
> trigger a
> "for line in sale_order_line:" or similar
> is executed explicitly
>
> IMHO inside a transaction a re-read of a line must only happen after a
> DB-write of the current process, as the content can not change otherwise.
>
> caching the results of the first read would dramatically increase
> performance
>
>
> thanks for looking into this
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>
>