@simahawk@reis_pt You are totally right: freezegun is the right tool for freezing dates. The point of the slide was to show an example that is very easy to understand.
@bouvyd @reis_pt Not everything can be flushed later:
- create() performs INSERTs immediately;
- unlink() performs DELETEs immediately;
- many2many updates are performed immediately (if the relation needs some update).
Actually only updates on table columns can be flushed later.
@bouvyd @reis_pt Correct, the equivalence with commands is something like:
self.related_ids = rset
is equivalent to
self.write({'related_ids': [(6, 0, rset.ids)]})
self.related_ids |= rset
is equivalent to
self.write({'related_ids': [(4, id) for id in rset.ids]})
@stefan_opener Note that a computed field may be declared as depending on context values and uid: see decorator depends_context(). In that case, the cache will hold separate values for different context/uid.
@stefan_opener I guess you refer to the "record cache". This cache is *never* shared across requests, as the cached values depend on the current database transaction.
@PedroMBaeza @bouvyd In the case of a many2many, if A.subrecords = A1+C1 and B.subrecords = B1+C1, then (A+B).subrecords = A1+C1+B1 (the second occurrence of C1 has been discarded).
@PedroMBaeza @bouvyd (A+B).subrecords = (A+B).mapped('subrecords'), i.e., (A1+A2) | (B1+B2) (a union of recordsets, returning them in order of first occurrence). So, in the case of a one2many, subrecords are disjoint, and therefore (A+B).subrecords = A1+A2+B1+B2 (in that order).