Thursday, December 2, 2021
4 changes · master
Enhancements to existing features
Sales-related calculations are now applied automatically and consistently across the app, whether orders are created through the interface or other processes. This cleanup reduces duplicated logic and improves performance when creating or updating sales orders, without changing expected business behavior.
Original PR description
Purpose ======= This is the first step of a technical cleaning of the sales application. The final goal is to reduce the technical debt and improve the performances / readability of the related…
Purpose
=======
This is the first step of a technical cleaning of the sales
application. The final goal is to reduce the technical debt
and improve the performances / readability of the related
applications.
Some complex onchange methods containing purely business code
are defined, and called manually wherever the modifications
should be applied. This is a bad practice as there could be
a different business logic when making the same flow in the
interface or with python code.
Since #80449, it is now possible to add the precompute attribute on
stored computed fields to compute them before the insertion into the
database.
The idea is to convert this business code into compute methods to
apply it every time this is needed.
This is quite useful in our case in the sales application, as some of
the computed fields are required, and request some hacky overrides:
- in the create method, to simulate the onchange on new records, and
to update the values dictionary
- in the default_get method, to set a default value, which has to
side effect to prevent the field to be recomputed afterwards, which
could also lead to inconsistencies.
This made impossible to convert the onchange methods into compute
methods.
Now, that is possible to precompute the fields before the database
insertion, it is now possible to remove all this crappy overhead,
to benefit from the batch method definitions, and to avoid creating
fake records to simulate the values that we should have computed
before.
On the other hand, this is the occasion to write some methods
(create, ...) in batch, to remove some dead code, to simplify
the api, to reorganize the code using our coding guidelines.
Results
======
The benefit of calling the computes in batch doesn't only bring
functional consistencies, it also allow to improve the performances
without changing any existing features.
For example, let's have a look at the execution time and queries to
generate 1000 sales orders with 10 products lines each + 1 section
line, for 1000 different customers and shared between 2 salesmen.
We consider the "batch" time, aka the time to call the "create" method,
the flush time and the number of SQL queries.
In master:
BATCH: 121.97 seconds
FLUSH: 24.05 seconds
# queries: 53103
Now:
BATCH: 113.07 seconds
FLUSH: 1.22 seconds
# queries 22057
This means a reduction of:
- 7.2% for the batch time
- 95% of the flush time
- 21.7% for the total time
- 58.5% for the number of SQL queries
Note that the effect of the precompute, the onchange methods
conversions, and the optimizations on this PR are emphasized
when the sales orders are related to the same partners.
If we take a look at the flamegraphs when creating 100 sales orders
of 3 lines each, we directly spot that the methods are now called once,
which also justify the large decrease of execution time and SQL queries.
Master:
Now:
TaskID: 2679099
Co-authored-by: Victor Feyens vfe@odoo.comThe master release version has been updated to 15.2. This keeps the product version information aligned for upcoming releases and internal tracking.
Sales-related calculations now run automatically and consistently whether changes are made by users or through back-office processes. This cleanup reduces duplicated logic, improves reliability across connected apps, and should improve performance without changing existing sales features.
Shared signing links now create the final signing request only when someone actually signs, reducing unused records from casual link clicks. The person who shares the link is also kept as the sender of completed requests, so they retain access to the signed document, and the Share button appears in the right template scenarios.
Original PR description
1. The dummy sign.request is created for the user who clicks the share button and create the share link. As a result, the link sharer of the final sign.request will be the creator of the completed sign.request and always has its read permission 2. It uses the `copy_on_write` logic. As a result, no matter how many users clicks the share link. New sign.request are only created after they actually sign. There is one redundant dummy sign.request in the database. The user can manually delete the dummy sign.request to stop the sharing. Before this commit: 1. All internal users share the same template share_link. So the creator(sender) of the new sign.request can only be one person(the creator of the sign.template). As a result, the sender of the share link maynot have the read permission of the completed sign.request. 2. It uses the `copy_on_read` logic. As a result, the server will create a new sign.request for every click of the share_link. And some of them will never be completed.
Original PR description
Purpose ======= This is the first step of a technical cleaning of the sales application. The final goal is to reduce the technical debt and improve the performances / readability of the related…
Purpose
=======
This is the first step of a technical cleaning of the sales
application. The final goal is to reduce the technical debt
and improve the performances / readability of the related
applications.
Some complex onchange methods containing purely business code
are defined, and called manually wherever the modifications
should be applied. This is a bad practice as there could be
a different business logic when making the same flow in the
interface or with python code.
Since #80449, it is now possible to add the precompute attribute on
stored computed fields to compute them before the insertion into the
database.
The idea is to convert this business code into compute methods to
apply it every time this is needed.
This is quite useful in our case in the sales application, as some of
the computed fields are required, and request some hacky overrides:
- in the create method, to simulate the onchange on new records, and
to update the values dictionary
- in the default_get method, to set a default value, which has to
side effect to prevent the field to be recomputed afterwards, which
could also lead to inconsistencies.
This made impossible to convert the onchange methods into compute
methods.
Now, that is possible to precompute the fields before the database
insertion, it is now possible to remove all this crappy overhead,
to benefit from the batch method definitions, and to avoid creating
fake records to simulate the values that we should have computed
before.
On the other hand, this is the occasion to write some methods
(create, ...) in batch, to remove some dead code, to simplify
the api, to reorganize the code using our coding guidelines.
Results
======
The benefit of calling the computes in batch doesn't only bring
functional consistencies, it also allow to improve the performances
without changing any existing features.
For example, let's have a look at the execution time and queries to
generate 1000 sales orders with 10 products lines each + 1 section
line, for 1000 different customers and shared between 2 salesmen.
We consider the "batch" time, aka the time to call the "create" method,
the flush time and the number of SQL queries.
In master:
BATCH: 121.97 seconds
FLUSH: 24.05 seconds
# queries: 53103
Now:
BATCH: 113.07 seconds
FLUSH: 1.22 seconds
# queries 22057
This means a reduction of:
- 7.2% for the batch time
- 95% of the flush time
- 21.7% for the total time
- 58.5% for the number of SQL queries
Note that the effect of the precompute, the onchange methods
conversions, and the optimizations on this PR are emphasized
when the sales orders are related to the same partners.
If we take a look at the flamegraphs when creating 100 sales orders
of 3 lines each, we directly spot that the methods are now called once,
which also justify the large decrease of execution time and SQL queries.
Master:
Now:
TaskID: 2679099
Co-authored-by: Victor Feyens vfe@odoo.com