Merge lp:~openerp-dev/openobject-server/6.0-opw-577963-msh into lp:openobject-server/6.0
Status: | Rejected |
---|---|
Rejected by: | Olivier Dony (Odoo) |
Proposed branch: | lp:~openerp-dev/openobject-server/6.0-opw-577963-msh |
Merge into: | lp:openobject-server/6.0 |
Diff against target: |
38 lines (+8/-13) 1 file modified
bin/addons/base/ir/ir_attachment.py (+8/-13) |
To merge this branch: | bzr merge lp:~openerp-dev/openobject-server/6.0-opw-577963-msh |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Olivier Dony (Odoo) | Disapprove | ||
Mohammed Shekha(Open ERP) (community) | Abstain | ||
Review via email: mp+120138@code.launchpad.net |
Description of the change
Hello,
Fixed the issue of ir_attachment which reads all the records for checking ir.access due to which ir_attachment tree view becomes to slow even if it loads only 20 records, changed the code and do the same with DISTINCT res_model, if user don't have rights then and only then read the ids of that object and remove it from ids.
When we click on document menu so it will read first 20 records and then it will call search_
So fetched all distinct res_model and check it with ir.access and read only those ids on model on which user don't have access, this way it will save the time of fetching search result.
I have scenario in which I have 90000 attachments and loading of document tree view with only 20 records taking approximately 10 second, after this patch it will take 3 to 4 second.
Thanks.
Unmerged revisions
- 3633. By Mohammed Shekha(Open ERP)
-
[FIX]Fixed the issue of ir_attachment which reads all the records for checking ir.access due to which ir_attachment tree view becomes to slow even if it loads only 20 records, changed the code and do the same with DISTINCT res_model, if user don't have rights then and only then read the ids of that object and remove it from ids.
This is not correct, the logic for filtering based on access rights was already done efficiently.
Your patch makes it check the access right of only 1 document of each model, but every document may have different access restrictions depending on access rules (e.g. multicompany, etc.).
BTW the OPW case has already been closed and a different patch was merged, so you don't need to work on this anymore.
The bulk of the performance problem with large databases was caused by the numerous calls to list.remove(), which are very slow on large lists. Using a set() instead made it a lot faster (50s -> 3s for a real database with 100k random attachments). Your measures were a lost faster than that, probably because most attachments were duplicates and therefore attached to the same (model,res_id) - biasing the result heavily.
Thanks,
PS: why did you review your own MP with "Abstain"?