c2c-oerpscenario team mailing list archive
-
c2c-oerpscenario team
-
Mailing list archive
-
Message #32815
[Bug 798732] Re: hr_timesheet_sheet: Timesheets big performance issues
Hello Guewen Baconnier,
The reason behind doing that is, if we apply your solution for
hr_timesheet_sheet_sheet_day init method, following is the result :
Date From : 22/9/2011
Date To : 22/9/2011
Attendances
-----------------
Date Action Employee's Name
2011-09-22 10:00:00 sign_in Administrator
2011-09-22 13:00:00 sign_out Administrator
2011-09-22 14:00:00 sign_in Administrator
2011-09-22 19:00:00 sign_out Administrator
Period (In Summary Tab)
---------------------------------
Date Attendance Total Timesheet Difference
2011-09-22 24.0 8.0 16.0
It takes 24.0 Hours in Attendance(Consider's whole day) instead of
Actual Working Hour i.e (8 hours). And by keeping the same view for in
init method it considers Actual working hous, which is correct according
to fuctionality. following is the result obtained if we use the existing
view :
Date Attendance Total Timesheet Difference
2011-09-22 8.0 8.0 0.0
Hope this will help you.
Thanks & Regards,
Devnani Bharat R.
--
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to OpenERP Project Group.
https://bugs.launchpad.net/bugs/798732
Title:
hr_timesheet_sheet: Timesheets big performance issues
Status in OpenERP Addons (modules):
Fix Committed
Bug description:
Hello,
We are experiencing major problems of performance on timesheets.
OpenERP 6.0.2
Performance issues occur with the module hr_timesheet_sheet.
We have ~ lines per tables :
- hr_timesheet_sheet : 7'500
- hr_analytic_timesheet : 110'000
- hr_attendance : 110'000
Opening the "Timesheets" menu takes a few minutes for the 80 first rows.
Then open the timesheet form view takes nearly 30 seconds.
Each action on a timesheet (Sign-in/out, fill a timesheet line, ..) takes nearly 30 seconds again.
It's clear that the main cause of the problem is : hr_timesheet.sheet.day
This view computes the indicators for the whole tables and only afterwards we get the rows that we need.
The second cause of the problem is the fields sheet_id in
hr.attendance and hr.analytic.timesheet which are function fields.
The function fields total_attendance_day, total_timesheet_day,
total_difference_day, total_attendance, total_timesheet,
total_difference of hr_timesheet_sheet.sheet are based on this view,
so that's why each action on the timesheet take 30 seconds, because
the view is computed again and again.
Here is the actions that I found to bring an acceptable situation:
- Removed the "By Day" page on the timesheet view, instead I added a link which open a new view (this will still be slow but it can be acceptable as a first solution as you decide to open it...).
- I replaced the methods to compute the hr_timesheet_sheet.sheet function fields by full python instead of a cr.execute() on the view.
- There is still a bottleneck, on a search of sheet_id in hr.attendance and hr.analytic.timesheet, it executes each time a sql query. I added store=True to the function field. The only issue I see with that is in the case of a modification of the employee_id of the timesheet, we can add a trigger on this modification, but I don't see how we can search lines to update. What are your thoughts ? (Is it useful to change the employee of a timesheet after its creation, can we block this ?)
This improves a lot the performances, but there is still a lot of room
to improve them !
Maybe we have to replace this function fields / one2many_mod with
one2many fields ?
Here is the link to my branch (I propose a merge.)
https://code.launchpad.net/~gbaconnier-c2c/openobject-addons/6.0-hr_timesheet_sheet-performance-improvements
Thanks
Guewen
To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/798732/+subscriptions
References