openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello,

I suggested already to create such an "EAV" pattern (attribute tables)
indeed for OpenObject:
https://blueprints.launchpad.net/openobject-server/+spec/base-eav-module
However, it's very important not abusing it either. In the Magento
ecommerce, the guys went full EAV pattern at first cause it was the simplest
for them: once they implemented their EAV crap, it was easier for them to
use it always for any attribute instead of having a decent DDL migration
engine such as OpenERP. Result: even sorting products by price in Magento
hit the EAV bloated tables...
Anyone, used to Magento would know that this is the SQL pattern (along with
the use of PHP) that make Magento dog slow for anything that can't be
cached:
http://inchoo.net/ecommerce/magento/escape-from-eav-the-magento-way/

So, yes, I'm for an EAV pattern in OpenObject, as long as it's used only to
store some sparse attributes with very occasional search operations upon
them (but yes this let room for many attributes indeed).

I also recall one general principle: OpenERP doesn't have sufficient
technology/consistency/functional scope to attract large companies massively
yet. As it is, it really targets 10 - 50 employees SMB's (until it get clean
+ complete enough eventually). Those small SMB's don't really have large
perf impact of using OpenERP. Perf trouble lies elsewhere eventually: too
many HTTP requests (like the like of search_read in the GTK client etc...),
too many clicks (cause of the lack of genericness of some widgets), widgets
like many2many that were not paginated in v5, slow Python execution (top
typically shows at least 40% of CPU usage in the Python part, some smart
combo like Java/Mirah/Jython/JRuby would have allow to externalize some of
the Python slowness to C fast languages that are still portable
and reasonably powerful (I believe that Scala or Duby/Mirah are just as
powerful as Python while featuring C speed and retaining a runtime
compatibility with a Python impl (Jython) )). Some of the Python overhead
would also be removed if we were using a smartest ORM (SQLAlchemy?) that
would allow to abstract more complex SQL requests in Python rather than
multiplying the DB calls and Python overhead as it is done currently all
over the place in the modules (search/search/browse/relation sequences).

Finally, I have some doubts: Sharoon, didn't you start some EAV pattern
already?

Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com




On Fri, Jul 9, 2010 at 12:35 PM, P. Christeas <xrg@xxxxxxxxx> wrote:

> In a recent commit, I just noticed another module that inherits
> "res.partner"
> and adds 3-4 columns.
> Counted the columns in one db, and found 50.
>
> I think we're doing something wrong here.
>
> Many modules need to store information per partner. They just add extra
> fields
> in the table. They also add one boolean field "is_member", "is_employee",
> "is_clown" etc.
> The same, of course, may be true for other tables, like product, for
> example.
>
> I suggest, generally, that we avoid this pattern in setting up our schema.
> My
> feeling is that we waste resources (although pg's toast does compression)
> in
> storing NULLs for all these columns.
>
> At least, these booleans could be somehow covered by the partner
> categories.
> Then, other explicit data per partner, could be put in an "attributes"
> table.
>
> wdyt?
>
> _______________________________________________
> 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
>