openerp-expert-framework team mailing list archive

[Ferdinand Gassauer <office@xxxxxxxxxx>]

On Friday 09 July 2010 P. Christeas 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?
you are right, one could put these additional data in an attributes table, BUT 
then the ORM has to be changed to allow domain specifications in XML using 
this attribut table
instead of 
'is_employee','=','1'
we would need
'attribute_table.code', '=', 'employee' - which currently in V5 is not 
implemented

BTW currently we have big problems - we are trying to solve them with stored 
functional fields to allow search in forms

store  = {'module.table' : (lambda self, cr, uid, ids, ctx: ids, 
['something_id'], 10)}

I do not consider this programmer friendly

IMHO it's critical to allow a more flexible search defined in XML
> 
> _______________________________________________
> 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
> 
-- 
regards
Ferdinand Gassauer
ChriCar Beteiligungs- und Beratungs- GmbH
Official OpenERP Partner