[6.1][account] slow large invoice validation because validate is called for every line
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Addons (MOVED TO GITHUB) |
Won't Fix
|
Low
|
Unassigned | ||
6.1 |
New
|
Undecided
|
OpenERP Publisher's Warranty Team |
Bug Description
edit account/account.py
and introduce some traceback print statement this way:
@@ -1378,6 +1385,9 @@
# Validate a balanced move. If it is a centralised journal, create a move.
#
def validate(self, cr, uid, ids, context=None):
+# import traceback
+# traceback.
+ print "validate", ids
if context and ('__last_update' in context):
del context[
Now restart your server and try to validate an invoice with many lines, like 10 (cool you are not in production).
As you can see, that slow validate method is called for every invoice line, making the whole process very slow. Here in production it takes like 2 minutes to validate a 50 lines (with Brazilian taxes) invoice... Not very user friendly.
You'll see a similar traceback for every line:
File "/opt/openerp-
return lambda *args, **argv: attr(self._cr, self._uid, [self._id], *args, **argv)
File "/opt/openerp-
self.
File "/opt/openerp-
return super(account_
File "/opt/openerp-
result = super(account_
File "/opt/openerp-
result += self._columns[
File "/opt/openerp-
self.
File "/opt/openerp-
model.write(cr, uid, [t_id], {args[-1]: values}, context=context)
File "/opt/openerp-
self.
File "/opt/openerp-
traceback.
validate [543]
In "/opt/openerp-
It will actually birth inside the ORM in "/opt/openerp-
where you'll iterate over each id.
I tend to think this is a first bad implementation, may be the real source of the bug. After this, we call validate for each account move line...
Still, it looks like you attempted to prevent this by strong a context c['novalidate'] = True flag.
a grep gives us:
~# grep -r novalidate /opt/openerp-
/opt/openerp-
/opt/openerp-
But as you can see, it's a bit like marketing: totally useless. Sounds like a good intention but it has absolutely no effect at all, it's just no used.
So, I let you determine what is the proper fix, something in the ORM or some "novalidate" trickery before somebody remove the trick by mistake again to fox some side effect bug...
Hope this helps.
Related branches
- OpenERP Core Team: Pending requested
-
Diff: 21 lines (+2/-2)1 file modifiedaccount/account_move_line.py (+2/-2)
- Stefan Rijnhart (Opener): Approve
- Pedro Manuel Baeza: Approve (code review)
-
Diff: 21 lines (+2/-2)1 file modifiedaccount/account_move_line.py (+2/-2)
Changed in openobject-addons: | |
status: | Incomplete → New |
Changed in openobject-addons: | |
assignee: | OpenERP R&D Addons Team 3 (openerp-dev-addons3) → nobody |
tags: | added: maintenance |
I can confirm this problem, we have experienced it on the Spanish localization for OpenERP 5.0 when undoing the fiscal year closing (the fiscal year closing wizard of the Spanish localization allows to undo the closing operations anytime).
On a normal production database, creating the fiscal year closing move (a big move, as it has a line per non-zeroed account) takes about 2 to 4 seconds, deleting the same move takes 20 to 40 seconds.