openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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 <davide.corio@xxxxxxxxxxxx>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     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>