1.many2one是用来建立两个表之间的关联的,必须在子表里定义一个字段(实体表里也会生成这个字段),指向主表的model。
例如:course和session的关联里,session子表的model里就要定义一个course_id,指向主表的一条记录。
一个session里只能有一个course,一个course里有过的session。
course_id = fields.Many2one('openacademy.course',
ondelete='cascade', string="Course", required=True)
2.one2many是一个虚拟关系,定义了也不会在实体表里创建字段的。在主表里定义,指向明细表的model,并且必须指定明细表里定义的和主表相关联的字段。必须先定义many2one之后才能定义one2many。
例如:course主表里可以定义一个session_ids代表子表的一个集合。
session_ids = fields.One2many(
'openacademy.session', 'course_id', string="Sessions")
3.many2many会创建一个两个实体表的主键的新的关联表。关联表为两个实体表名加_rel。
例如:session里定义一个出席者的字段。一个session里可以有多个 Attendees,一个attendee也存在于
多个session里,这时就要定义两个表的关联关系表。
attendee_ids = fields.Many2many('res.partner', string="Attendees")
4.fields.related。
生产批次model
'partner_id':fields.many2one('res.partner',string=u'客户',),
'name':fields.char(u'生产批次',copy=False),
'partner_lot':fields.char(u'客户批次号',),
'product_id':fields.many2one('product.product',string=u'客供代码'),
'product_name':fields.related('product_id','name',type='char',string=u'品名',),
'tse_code':fields.related('product_id','tse_code',type='char',string=u'TSE代码',),
'product_qty':fields.integer(u'制造量'),
生产单model,一个生产批次有多个生产单
'plot_id':fields.many2one('mrp.pro.lots',string='生产批次'),
'routing_no':fields.integer(u'工序批次'),
//这里的related写法还不明白。是否是因为不是获取单纯的关联表里的某个单纯字段的原因?
是因为获取的partner_id在生产批次model里也是many2one的集合的原因呢?但是为什么partner_lot
不能按照上面的简单的写法写
'partner_id':fields.related('plot_id','partner_id',type="many2one",relation="res.partner",string=u"客户",
store={
'mrp.production': (lambda self, cr, uid, ids, c=None: ids, ['plot_id',], 30),
'mrp.pro.lots': (_get_partner_id, ['partner_id',], 30),
}),
'partner_lot':fields.related('plot_id','partner_lot',type="char",string=u"客户批次号",
store={
'mrp.production': (lambda self, cr, uid, ids, c=None: ids, ['plot_id',], 30),
'mrp.pro.lots': (_get_parlot_id, ['partner_lot',], 30),
}),
class mrp_production(osv.osv):继承osv.osv是7.0的写法?找到osv.fields下面的fields.function方法
下面有store相关的注释。
.. _field-function-store:
.. rubric:: The ``store`` parameter
The ``store`` parameter allows caching the result of the field computation in the
database, and defining the triggers that will invalidate that cache and force a
recomputation of the function field.
When not provided, the field is computed every time its value is read.
The value of ``store`` may be either ``True`` (to recompute the field value whenever
any field in the same record is modified), or a dictionary specifying a more
flexible set of recomputation triggers.
A trigger specification is a dictionary that maps the names of the models that
will trigger the computation, to a tuple describing the trigger rule, in the
following form::
store = {
'trigger_model': (mapping_function,
['trigger_field1', 'trigger_field2'],
priority),
}
A trigger rule is defined by a 3-item tuple where:
* The ``mapping_function`` is defined as follows:
.. function:: mapping_function(trigger_model, cr, uid, trigger_ids, context)
Callable that maps record ids of a trigger model to ids of the
corresponding records in the source model (whose field values
need to be recomputed).
:param orm model: trigger_model
:param list trigger_ids: ids of the records of trigger_model that were
modified
:rtype: list
:return: list of ids of the source model whose function field values
need to be recomputed
* The second item is a list of the fields who should act as triggers for
the computation. If an empty list is given, all fields will act as triggers.
* The last item is the priority, used to order the triggers when processing them
after any write operation on a model that has function field triggers. The
default priority is 10.
In fact, setting store = True is the same as using the following trigger dict::
store = {
'model_itself': (lambda self, cr, uid, ids, context: ids,
[],
10)
}