I’ve been hooking into the OpenERP ORM layer of a few of the models to add full text search via an external engine. Thanks to the way OpenERP is structured that appears to be quite a reliable approach. As I was doing it I found that I wanted a common set of hooks on several models. Doing that suggested I should refactor the hooks to a mixin or a base class. After playing about with my OpenERP module I’ve come to the conclusion that creating a base class seems to be the most reliable way to hook the methods. The one trick you need to be aware of is the _register
flag that you want to set to False
for your base class.
class search_base(osv.osv): _register = False def write(self, cr, user, ids, vals, context=None): success = super(search_base, self).write(cr, user, ids, vals, context) … do stuff return success class product_template_search(search_base): _name = "product.template" _inherit = "product.template" _register = True class product_search(search_base): _name = "product.product" _inherit = "product.product" _register = True product_search() product_template_search()
Without that you’ll end up with the orm whining that the search_base
class has no _name
attribute as it tries to register it as a model.
openerp.osv.orm: The class search_base has to have a _name attribute openerp.netsvc: ValueError The class search_base has to have a _name attribute > /usr/lib/pymodules/python2.7/openerp/osv/orm.py(967)__init__() -> raise except_orm('ValueError', msg)
Why not just follow what is done in standard modules, like crm.case:
class product_template_search(search_base, osv.osv)
This doesn’t rely on internal implementations of the ORM that could be changed in newer versions.
To tell the truth I was going to do that, but it didn’t appear to work. I think I may have just realised why however. I’ll have to give it another go. Thanks for pointing that example out.