2012/8/15 Raphael Valyi <[email protected]> > > SOn Wed, Aug 15, 2012 at 12:54 AM, Raphael Alla <[email protected]> > 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. _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
