Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MERGE][REF] base, *: Compute fields before creation. #42560

Open
wants to merge 12 commits into
base: master
from

Conversation

@Feyensv
Copy link
Contributor

Feyensv commented Jan 2, 2020

Currently, the computed fields are computed after record creation in DB. This means that computed fields cannot be required and that no SQL constraints can be based on those fields.

To support required and sql constraints on computed (and stored) fields, we need to compute the fields before record creation ...

Side features/changes

pre_compute field attribute

Specify fields as pre_compute=False to ensure they are computed after record creation

  • Done by default if any compute dependency is pre_compute=False
  • Done by default if field depends on create_date/write_date/create_uid/write_uid
  • Done manually for part of existing fields (mainly statistics fields)
Postpone NOT NULL AND SQL constraints after fields/models computation/setup

Column are set to NOT NULL after fields computation in DB to ensure model extension with required computed fields works fine.

New Record cannot impact real records And inversely

To pre-compute computed stored fields, we instantiate a new record with the values given to the create call. This meant that two records were put in cache for one creation (one real and one new).
When a record is created linking to real records in o2m or m2m fields, the inverse was triggered and you could have new records in the relational fields of real records.

Example:
Create an account.move.line, linking to real account.move 1, if you accessed the lines from the account.move, you would receive 2 records (one new and one real).

To ensure the new new() call in the create() method doesn't impact real records, the inverse of new (resp. real) records changes is not applied on real (resp. new) records anymore. It was already the strategy of the orm, but is more strictly applied from now on.

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

@C3POdoo C3POdoo added the RD label Jan 2, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from 41a5c21 to 581d695 Jan 2, 2020
@robodoo robodoo removed the CI 🤖 label Jan 2, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from 581d695 to 8b04c09 Jan 3, 2020
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 3, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch 3 times, most recently from af80cc7 to d214790 Jan 6, 2020
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 6, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch 2 times, most recently from 8635d5b to e01de8e Jan 7, 2020
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 7, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch 2 times, most recently from f82dc96 to 083d86a Jan 8, 2020
@robodoo robodoo added the CI 🤖 label Jan 9, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from 38a9edb to f967a51 Jan 9, 2020
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 9, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from f967a51 to cfb4348 Jan 10, 2020
@robodoo robodoo added the CI 🤖 label Jan 14, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from a766af1 to 2233921 Jan 16, 2020
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 16, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from 04ca19a to 2233921 Jan 16, 2020
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 16, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from a176734 to 3cf7418 Jan 17, 2020
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 17, 2020
Feyensv added 11 commits Jan 13, 2020
Until now, stored compute fields were computed after database insertion.

This meant that required fields or constraints couldn't be used on 
computed fields, unless a default was specified.

But using a default meant that the field wasn't computed after insertion 
either, because it was protected against recomputation.

#### Pre_compute=False fields

We sometimes do want to explicitly compute some computed stored fields 
AFTER INSERT, mainly:

* statistics fields computed with search/read_group/...
* fields potentially referencing the current record (e.g. 
res.partner.commercial_partner_id)
* field referencing the first one of a m2m/o2m relational field (only if 
stored)
* fields depending on the create_date/write_date/create_uid/write_uid
...

Those fields can be specified as pre_compute=False to force their 
computation post record creation.
Make sure SQL constraints can apply on compute store fields,
even for modules extensions.

SQL constraints can apply after module creation for new models, because
the new model table is empty (no row to invalidate the constraints).

But for extended models, we have to apply SQL constraints (and required)
after compute store computation, otherwise the constraint may not be applicable
to current records because the compute stored columns are empty (not already computed).
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from 3cf7418 to 482408d Jan 20, 2020
@robodoo robodoo removed the CI 🤖 label Jan 20, 2020
@Feyensv Feyensv force-pushed the odoo-dev:master-create-vfe branch from 482408d to a17f730 Jan 20, 2020
@robodoo robodoo added the CI 🤖 label Jan 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.