This question is perhaps more complicated than it would initially seem.
Let’s say I have a parent class Animal (we name it in OpenERP as animal.base). I also have subclasses Lion (animal.lion) and Elephant (animal.elephant). I need to be able to create a view with a many2one field that can refer to any subclass of Animal. This seems to work by doing the following:
class animal_lion(osv.osv):
_name = 'animal.lion'
_inherits = {'animal.base': 'base_id'}
_columns = {
...
'base_id': fields.many2one('animal.base', "Base ID")
}
def roar(self, cr, uid, context=None):
print "rarrrrr"
Now when we create an instance of animal.lion we can see that it is visible in views that reference animal.base. (Plain inherit = 'animal.base' does not behave this way, FWIW.)
However, now let’s say we need to use a method from this animal. Since the many2one refers simply to animal.base, we have no idea what kind of animal the user selected in the view. Even if we happen to know that only lions will ever be chosen, we can’t call roar because the animal.base object will only let us call methods that are defined on itself. We can try to hack around it by naming the method emit_sound and trying to override the method in the Lion class. This will at least run (once you add an _inherit in addition to the _inherits) but it won’t produce the correct Lion-specific output. What is needed is some way to determine the dynamic type of the specific instance that was chosen in a many2one on base class x where multiple subclasses specify _inherits on that same class x. Imagine a fictional method get_subtype(). Then we can say the following in our button handler for the view:
def perform(self, cr, uid, ids, context=None):
this = self.browse(cr, uid, ids[0], context)
subtype_name = this.my_many2one.get_subtype()
subtype = self.pool.get(subtype_name)
# will produce a roar if user picked a lion, else a meep
subtype.emit_sound(cr, uid, context)
Alternatively, is there any other architecture that can be used to accomplish the same task? (Yes, I contrived the example, but it should illustrate the real issue.) [Perhaps encode the subtype name in a field in each subtype instance? ]
I am restricted to OpenERP v5, but would be interested to know the answer for any version.
The key here is that you want your
base.animalto exist on its own in the database as a common index of all animals, so this complicates your data model substantially and forces you to use record-level inheritance (via_inherits).In order to resolve the subtype for an animal you should add an explicit
typecolumn inanimal.base, and always set it properly so you can infer the subtype record.Your
base.animalswill exist in the database on their own and can have their own views, because you’re using a record-level inheritance. The subtype (e.g lion) can be seen as a “decoration” for each animal, and it might actually not be unique (both abase.lionand abase.elephantrecord could exist for the samebase.animalrecord), so you should add uniqueness constraints somewhere.Now, you should never have both
_inheritand_inheritspointing to the same parent model, these two inheritance schemes are really meant for different purposes, as explained in the OpenERP technical memento.Instead you can have proxy methods in
animal.basethat will roughly look like yourperformmethod, except they need to find out the ID of the child records in addition to their type, e.g.:Of course you could refine this in several ways, for example with function fields added to
base.animalto automate more of this plumbing work.On the other hand, if you don’t really need the
base.animalto exist next to the other real animals, but simply need a way to select an arbitrary animal in a form view, you could try to use the traditional inheritance with_inherit+_name, withbase.animalbeing an abstract base class for them (without actually holding any record).Selecting an arbitrary animal could them be done with a
fields.reference, on which you can filter the list of destination models. The 5.0subscriptionmodule contains an example with thedoc_sourcefield.Watch out,
fields.referenceis something hybrid that does not integrate seamlessly with e.g.browse,readorsearch. It’s stored as a string in the form'model,id'and you’ll have to split the value manually whenever you need to dereference it – so be careful if you go that path. The only place where it’s integrated as a pseudo-many2oneis on the client UI, everywhere else it’s just a plain, dumb string value.