View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0001558 | Pending Requests | Project Designer | public | 2014-05-29 13:24 | 2016-12-26 10:25 | ||||||||
Reporter | opto | ||||||||||||
Assigned To | |||||||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||||||
Status | new | Resolution | open | ||||||||||
Product Version | |||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0001558: bad efficiency of update tasks | ||||||||||||
Description | even if only % is changed, we always store. update sql might be better. In storing, we always update dynamics etc which is only necessary on date changes or relationship changes it is ca. 5000 queries to change % on 120 tasks, taking 20 seconds | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files |
|
![]() |
|||||||
|
![]() |
|
caseydk (administrator) 2014-06-06 22:23 |
The problem is that we don't know what has changed.. we're not doing any sort of audit logging or field change tracking. I'm going to push this to v4.0 so we can rethink tasks as a whole instead of these piecemeal solutions. |
![]() |
|||
Date Modified | Username | Field | Change |
---|---|---|---|
2014-05-29 13:24 | opto | New Issue | |
2014-06-06 21:07 | caseydk | Relationship added | has duplicate 0001532 |
2014-06-06 22:23 | caseydk | Note Added: 0003420 | |
2014-06-06 22:23 | caseydk | Project | v3.2 Release => v4.0 Release (Planning) |
2014-06-10 22:49 | caseydk | Target Version | => 4.0 |
2016-12-26 10:25 | caseydk | Project | v4.0 Release (Planning) => Pending Requests |