openerp-expert-framework team mailing list archive

[Leonardo Santagada <santagada@xxxxxxxxxxxx>]

2012/8/15 Raphael Valyi <rvalyi@xxxxxxxxx>
>
> SOn Wed, Aug 15, 2012 at 12:54 AM, Raphael Alla <raphael.alla@xxxxxxxxxxx> wrote:
>>
>> I am unsure if the issue is as bad as stated in the reading case, as in many cases the db themselves do the caching and do not perform over and over the same request.
>
>
> I may miss something, but I don't think Postgres do query caching by default. All it seems to do it caching the query plan (that's a start). Generally database query caching is more used in CMS application with a dummy invalidation based on timeouts and specific calls to cache invalidation. Unless I miss something Postgres doesn't feature some query caching that would get a smart invalidation logic based on which data is written in while some cache is kept. Disclaimer I'm not a postgres expert, please if I'm wrong tell me.
> IMHO the right place to have this invalidation logic is in the ORM itself with a rigorous "dirty" state tracking of the business objects.
>
>>
>> This said, given the complexity of an ORM, I am surprised that OpenErp decided to develop their own instead of using existing python ORM. A 3rd party ORM would have more features and would be easier to maintain as part of a wider community.
>> There used to exist an SqlAlchemy branch of openerp in launchpad somewhere, I wonder if this is still active or not and if openerp would be willing to use another library.
>

I get that they developed their own because there wasn't any good orm
10 years ago. Today I think the SQLAlchemy branch is fastest path to a
sane DB usage. No need to do query rewriting, just make OpenERP
postgresql only but using SQLAlchemy, later parts of it can be
rewritten to SQLAlchemy portable idioms and in the future we can have
a portable OpenERP. But first a fast OpenERP in postgresql is what we
need.

> I would also have loved reusing at least part of standard ORM's. Now, about that poor SQLAlchemy branch, I fear you are miss-informed. Did you know that this branch has the "very unique" (sarcasms) approach of database portability of reparsing every fucking Postgres SQL request and doing fucking reexp changes to them to make them fucking pseudo pass the installation process on MySQL? So, no, sorry, yet a new low end branch that will make us look unserious for many more years when serious people will analyse the history of OpenERP.