Odoo Help

Welcome!

This community is for beginners and experts willing to share their Odoo knowledge. It's not a forum to discuss ideas, but a knowledge base of questions and their answers.

7

Product attributes / dimensions / property structure: Best design?

By
CB
on 3/29/13, 1:52 PM 3,404 views

In an MRP context, I have several products that have varying attributes I need to keep track of. For example, we have Doors that need to track edge profiles / wood species / panel types and drawer pulls that we need to track, say, material and shape.

One approach would be to append all of the data to product.product:

class product_product(osv.osv):
    _name = _inherit = 'product.product'
    _columns = {
        'product_type': fields.selection(('', ''), ('door', 'Door'), ('pull', 'Pull')),
        'door_edge_profile': fields.char(size=40),
        'door_wood_species': fields.char(size=40),
        'pull_material': fields.char(size=40),
        'pull_shape': fields.char(size=40),
    }

This approach works, but is rather denormalized - all products have these extra fields, and they may or may not be used. The data is stored as columns appended to product.product.

Another approach is a separate class per product type:

class product_door(osv.osv):
    _name = 'product.product.door',
    _inherit = 'product.product',
    _columns = {
        'door_edge_profile': fields.char(size=40),
        'door_wood_species': fields.char(size=40),
    }

class product_pull(osv.osv):
    _name = 'product.product.pull',
    _inherit = 'product.product',
    _columns = {
        'pull_material': fields.char(size=40),
        'pull_shape': fields.char(size=40),
    }

This approach also works, but the data is now split between two tables, with a product_id column hanging off the child tables. This is nice because the code is easy to separate / deal with, but makes the UI component harder - The end user will need to visit a different section when editing door or pull details, and none of the existing views will incorporate any data about the door or product.

A third approach i've discovered is a little hacky, but works:

class product_door(osv.osv):
    _name = 'product.product.door',
    _columns = {
        'door_edge_profile': fields.char(size=40),
        'door_wood_species': fields.char(size=40),
    }

class product_pull(osv.osv):
    _name = 'product.product.pull',
    _columns = {
        'pull_material': fields.char(size=40),
        'pull_shape': fields.char(size=40),
    }


class product_product(osv.osv):
    _name = _inherit = 'product.product'
    _inherits = {
        'product.product.door': 'door_id',
        'product.product.pull': 'pull_id',
    }

This approach keeps the data in it's own tables, and composes the fields into the product instance. The effect on the UI is the same as option 2 (in that it's somewhat negative), and the data is nicely separated. However, this implies again that every product has door or pull attributes in terms of the db design.

I really like SQLAlchemy's inheritance mapping, so i'll use those names when i'm talking about them further.

The first example I showed, which seems like the "default way" people seem to add to OpenERP models, is single table inheritance.

The second example is Joined Table Inheritance, where the child tables point to their parent.

The third example is 'backwards' joined table inheritance, or composition.

====

Separate from these concerns is using, say, product_variant_multi and encode the product attributes as Dimensions. Or, one could not use Dimensions, and instead apply 'mrp.property' properties to the product. This is more of an EAV data store, but I'm not certain that this complexity is worth it.


So, how do most OpenERP users generally model their databases?

Thanks for the advice.

Thanks CB for the summary. That's a very pertinent question when we are dealing with large range of product and attributes!

However, I could not get your third example working on v7. Are you sure we can have both Class inheritance (same name (product.product)) and multiple inheritance from other tables at the same time, without changing the final table name? But that would be great as existing views would still be working.

I would add to the possible designs, the product_custom_attributes module.

Looking forward to reading other OpenERP users suggestions.

Gabriel
on 5/16/13, 2:15 PM

I believe the third method works, as OpenERP considers the composed columns as part of this object's columns via orm.BaseModel._get_column_infos. I think this would allow views and code to treat the columns in much the same way that normal columns in the first method would work. However, _inherits does not allow one to propagate method calls. The reason is the commented method orm.BaseModel.__getattr__ which has a note about breaking super(). Also, specifically in orm.BaseModel._read_flat, you can see that it iterates over the _inherits tables and adds the data to read()'s result.

CB
on 5/16/13, 3:59 PM

Your Answer

Please try to give a substantial answer. If you wanted to comment on the question or answer, just use the commenting tool. Please remember that you can always revise your answers - no need to answer the same question twice. Also, please don't forget to vote - it really helps to select the best questions and answers!

About This Community

This community is for professionals and enthusiasts of our products and services. Read Guidelines

Question tools

1 follower(s)

Stats

Asked: 3/29/13, 1:52 PM
Seen: 3404 times
Last updated: 3/29/15, 2:47 AM