Hello guys, I agree 100% not using the SQLAlchemy branch the way it is: it has been done in the dark with no peer review (what quality would you expect then?) and it adds some overhead indeed.
David, specifically, the overhead comes from the unique OpenERP approach: 100% of the ORM I know use some specific SQL DSL (Domain Specific Language) and then generate queries from that. ex: HQL on Hibernate, Arel on ActiveRecord, GQL on Google data store etc... But, because OpenERP largely re-inveted the wheel with their own ORM (disclaimer that's true there were no suitable Python ERP by the time, and that's also sure standard ERP's where missing a few features), they didn't go very far in the abstraction (cause they wasted resources re-inventing) and the SQL DSL is pretty limited to what we use in the domain feature. As a result, instead of using portable abstractions, OpenERP implementers started abusing raw SQL at every module corner to fit the gap. Of course, once the code is crippled by raw SQL specific statements, they are not easy to port at all... (that's why I never believed the Openbravo announcement they would be compatible with MySQL soon, that's pretty much believing the toothpaste can go back into the stick ;-) ) So, instead of biting the bullet and start abstracting that SQL, Tiny took the fantasist approach to try that: raw Postgres SQL -> parse it into an abstraction + errors + overhead -> re-genarate MySQL SQL + errors^2 + overhead^2 They even tried a LRU cache in front of that, but there would still be overhead and I'm really not sure how you can cache efficiently dynamic SQL requests. I believe they ended up disabling it. And because it has been developed in the dark, once the money flow stopped, nobody even tried to continue the effort... So, I mean, no problem if this was for marketing (and they did great!). But in any case, now they have the money and OpenERP is still not mature enough to fit a mass market, so I suggest dropping largely the marketing focus for a few months cause I think there is no point any more doing it: OpenERP S.A. already got the money, they don't run for a second round and a mass market need first a mature and generic ERP that is yet to be built now. Just like we integrators are totally flooded with our current projects because it's not that easy and takes time/skills, there is no point in hyping the thing even more as the guys won't find any valid integrator for now, that could even result in a lot of frustration trying to attract guys that do not fit with OpenERP the way it is currently. Make no mistake, the few guys able to work with OpenERP or buy that solution are smart enough to detect the product even with little marketing. BTW, I also think Postgres is the best option. Before when MySQL was independent and popular it could have attracted to some mindshare to try being compatible, but now that Oracle is burying it while the web users that were not really doing SQL with the easy/cheap MySQL are fleeing away massively to no-SQL easy/scalable solutions so I think it's just pointless. Now, it's always good to keep things abstracted, we never know, it's possible we need to cope with no-SQL at some point (certainly not for everything) in the future, having abstraction rather than raw SQL entropy would allow to adapt to that. PS: thanks xrg for the doc/effort, will try to look at it whenever we get a little integration rest ;-) My 0.02 R$ Raphaël Valyi http://www.akretion.com On Tue, Mar 16, 2010 at 6:37 PM, Davide Corio <[email protected]>wrote: > Il giorno mar, 16/03/2010 alle 22.24 +0100, Sébastien LANGE ha scritto: > > I agree with you, I prefer just using PG and not SQLAlchemy for the same > > raison. > > I believe that, at this point, SQLAlchemy could be just a marketing > instrument because you can talk about oracle, mysql and so on. > > if you really need oracle, maybe you can approach SAP. > if you need mysql, you're fool (we have already used mysql in big > projects, it's a mess). > > So, our choice for the moment is always postgresql. with openobject, > django, plone, zope and all of the other frameworks we usually use. > > but, to tell all the truth, i don't believe sqlalchemy would be such a > bottle neck. > > do you really think can worse performances? > > -- > Davide Corio > email: davide.corio<at>domsense.com > web: http://www.domsense.com > > > _______________________________________________ > 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 >
_______________________________________________ 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
