Merge lp:~tempo-openerp/openobject-server/keep_order_read-5.0 into lp:openobject-server/5.0
Proposed by
Quentin THEURET @Amaris
Status: | Rejected |
---|---|
Rejected by: | Olivier Dony (Odoo) |
Proposed branch: | lp:~tempo-openerp/openobject-server/keep_order_read-5.0 |
Merge into: | lp:openobject-server/5.0 |
Diff against target: |
12 lines (+1/-1) 1 file modified
bin/osv/orm.py (+1/-1) |
To merge this branch: | bzr merge lp:~tempo-openerp/openobject-server/keep_order_read-5.0 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Olivier Dony (Odoo) | Needs Resubmitting | ||
Review via email: mp+49052@code.launchpad.net |
Description of the change
Fixes the #715749 bug
To post a comment you must log in.
Unmerged revisions
- 2172. By Quentin THEURET <quentin@tempo-quentin>
-
[FIX] Keep the order of ids on the read ORM function
Quentin, thank you for the merge proposal, however we cannot accept such a change in stable branches, like 5.0 or 6.0.
You may want to re-submit against the trunk version only.
But even for trunk, this in-memory sorting of the results of read() can be a performance problem, and this is the reason why read() does not re-sort the result when it returns them.
Read() is basically a "SELECT [fields] from table where id in [ids]" which postgres has no reason to sort in the order of [ids]. To be able to do that, read() should receive the sort order to use, and thus pass it in the SELECT query.
This requires an API change, and in order to avoid duplicating the features of search() there, it would probably make sense to implement this as part of a new combined search_read() method, that would do both things at the same time, using postgres to implement the ordering efficiently.
Hope this helps.