Master new read group refactor tuple version ryv
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
@ryv-odoo Documentation PR? :pray:
Thank you for your input @william-andre
However, I don't understand your point about the array_agg:
It might be more deterministic, but it is not ensured
What do you mean ? id is always unique and not-null, then it is deterministic. Example of SQL expression generated: ARRAY_AGG("test_read_group_task"."name" ORDER BY "test_read_group_task"."id"). Or I miss something ?
the order of the ids might be the order of the _read_group
It doesn't make sense: the order of the read_group orders groups, but the order of array_agg should order inside a group it-self.
or the order of the model
It will generate extra join in case of many2one (also some _order of models are even not deterministic).
@robodoo rebase-ff r+
Merge method set to rebase and fast-forward.
@ryv-odoo @rco-odoo linked pull request(s) odoo/documentation#4064, odoo/enterprise#38639 not ready. Linked PRs are not staged until all of them are ready.
robodoo r+
Hi @ryv-odoo. Can you share any script fo apply this changes on custom code? (for eg. in OCA modules) Thanks!
Hi @ryv-odoo. Can you share any script fo apply this changes on custom code? (for eg. in OCA modules) Thanks!
I made a little script to help me when I changed the codebase of Odoo: https://github.com/ryv-odoo/odoo_scripts/blob/master/read_group_replacement.py
But of course it doesn't work perfectly (and it's not very clean). Because I changed the returned values, you still have to check every use of it.
Note that the old read_group (public method) doesn't change its behavior much (but it's not very efficient to use it in the backend).
Uou! Thanks a lot @ryv-odoo !
