Linearity is not always perfect, managing more template will sometimes lead to slighlty more than a linear ratio randomly. The maximum observed ratio was 10.9. 12 seems a good value to catch non linear treatment while avoiding false positive. closes odoo/odoo#59021 X-original-commit: 62610f7851f0994fc0864f2b95851ce8b5984ce7 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Performances from a general point of view can be difficult to track.
This commit proposes to improve logs in two ways:
The current logs only use the sql_counter, wich will only be updated
when a cursor is closed. In a test-enable install, this counter
is actually the queries of the tests wince the install cursor is
open untill the end. The first fix is to use bot sql_counter and
sql_log_count to have total queries untill now on closed cursor,
but also the current number of queries of the current cursor.
This means that the new log format will be
{nb} modules loaded in {time}, {loading_querie} (+{test_cr_queries}) queries
instead of
{nb} modules loaded in {time}, {tests_cr__queries}queries
Nothe that in the current version, {nb} is actually the total number of
loaded modules until now.
This commit also add an equivalent end log by module and change the
loglevel of module start on install (mainly usefull if an error occurs
before anything else is logged hidding the module causing this error.)
A cleaner runbot logger is also added, in order to be abble to call
_logger.runbot( instead of _logger.log(25. This will clarify the purpose
of such a log level.
closes odoo/odoo#47283
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
A good practice is to always prefix the name of a template by the name of the module it is defined in. So in the case where a template ```xml <t t-name="module.template" /> ``` was inherited by another Before this commit, one should have written ```xml <t t-name="other" t-inherit="module.module.template" /> ``` After this commit, it becomes more natural, and one should only write ```xml <t t-name="other" t-inherit="module.template"/> ```
Before this commit, there were some tests checking how long it took to compute a bunch of templates Those asserted a time limit, which is undeterministic After this commit, those performance tests are not executed as standard anymore Moreover, only asserts on ratios between computations is done and deemed relevant. closes odoo/odoo#43189 X-original-commit: 329fdf3961ea9e6eddbcba7a78d72102d2d08ac1 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when doing a primary inheritance the root node of the resulting template was the one of the inherited template after this commit, the root node of the resulting template is the one defined on the inheriting template closes odoo/odoo#39452 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when a template was inheriting from another the template mentionned its t-inherit This has been deemed overkill as the information is irrelevant to the caller i.e. the caller just wants the template and doesn't care how they've been computed After this commit, only t-name and attributes not related with inheritance are disclosed [FIX]: base: static inheritance propagates other attributes When doing a inherit in primary mode, the original attributes on the root node of the inheriting template were not propagated After this commit they are
At the conception of this feature it has been intentionally thought that the behavior for static templates should resemble what is done for ir.ui.view While keeping the general previous behavior (and this is important) A little bit of context for ir.ui.view They are defined as XML's, but end up as python objects Their meta-data (id, name, inheritance specs...) are thus present in their XML definition, but end up as part of python objects members Hence, the final, business, usable arch is free of those meta-data and is left only with business-relevant dom nodes The static inheritance feature was backed with those ideas but inherently encountered the issue that, for them, the meta-data also end up in the business dom, since they are at no point considered as plain objects. Decision has been made, back then, to exclude the root node that holds the metadata, to be at all targeted by any XPATH This decision is now challenged as the specs of XPATH should be respected This commit consequently introduces the root node as any other It can be replaced, and will be targeted by `expr="."` or `expr="//NODE_TAG"` The few attributes that are necessary to define them are kept across inheritance cycles though.
Have a parent template Have a child, in extension inherit mode of the parent The child has a xpath like `<xpath expr="." position="replace" />` Before this commit, there was a crash. That was because the Comment (which indicates which templates modified the parent) was taken as the replacer node instead of the actual content of the xpath After this commit, there is no crash, and it works as expected closes odoo/odoo#39453 X-original-commit: 02d790e1d21b78395e489f57bf30c82f728cbee6 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
closes odoo/odoo#39329 X-original-commit: e2d7cf7898704c82f25556b0b0edb87c05ec5903 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
QWeb templates that show up in the 'qweb' key of a module's manifest now support server side inheritance and xpath evaluation QWeb templates that show up in the xmlDependencies of a JS widget are not impacted at all by theses changes, as they are served through the Werkzeug sharedMiddleware A similar syntax than ir.ui.view has been implemented in the QWeb templates - each template must have a root node, whatever tag works - the root node of a template must have a t-name containing the name of the template The name -- without the module's name -- may contain dots pretty much anywhere Though what is recommended is only underscores in template names - if a template is to inherit from a parent, the root node has a t-inherit directive containing either the full name of the template it inherits from which is module_name.template_name or the name of the template, no module name necessary, if the parent template is in the same module - there are 2 modes of inheriting primary: copy the behavior of the parent into the template extension: modifies the parent in place Task: 1999528 closes odoo/odoo#33892 Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com> Co-authored-by: Julien Mougenot <jum@odoo.com> Co-authored-by: Lucas Perais <lpe@odoo.com>