Project:
| View Revisions: Issue #34770 | [ Back to Issue ] | ||
| Summary | 0034770: Add code to auto-detect 'accidental double query' on same OBQuery object | ||
| Revision | 2016-12-19 12:14 by caristu | ||
| Steps To Reproduce | In description | ||
| Revision | 2016-12-19 12:14 by caristu | ||
| Description | There is a quite common bad coding pattern which calls '.list()' more than one time on the same OBQuery object. That will call the underlying sql query also 2 times. Similar some code without good reason calls .count() + then .list() on the same instance. Which leads to a 'select count(*)' + then another 'select *' sql query. Detecting such pattern is easy with some extra debugging code inside those 2 utility classes. See attached patch for a rough patch doing some simple tracking. Not polished yet but did already find 6 issues in fast manual testing + more 'to be triaged' when running erp-try with it applied. The attached patch logs a WARN + a stacktrace of the location of and 2nd or 3rd call to either list,count,scroll.uniqueResult. In practice that 2nd location is enough as a pointer and finding the first call in code is very easy in all examples observed so far. |
||
| Revision | 2016-12-19 12:10 by caristu | ||
| Steps To Reproduce | https://issues.openbravo.com/view.php?id=33703 [^] https://issues.openbravo.com/view.php?id=33704 [^] https://issues.openbravo.com/view.php?id=33705 [^] https://issues.openbravo.com/view.php?id=33706 [^] https://issues.openbravo.com/view.php?id=33707 [^] https://issues.openbravo.com/view.php?id=33709 [^] |
||
| Revision | 2016-12-19 12:10 by caristu | ||
| Description | There is a quite common bad coding pattern which calls '.list()' more than one time on the same OBCriteria or OBQuery object. That will call the underlying sql query also 2 times. Similar some code without good reason calls .count() + then .list() on the same instance. Which leads to a 'select count(*)' + then another 'select *' sql query. Detecting such pattern is easy with some extra debugging code inside those 2 utility classes. See attached patch for a rough patch doing some simple tracking. Not polished yet but did already find 6 issues in fast manual testing + more 'to be triaged' when running erp-try with it applied. The attached patch logs a WARN + a stacktrace of the location of and 2nd or 3rd call to either list,count,scroll.uniqueResult. In practice that 2nd location is enough as a pointer and finding the first call in code is very easy in all examples observed so far. |
||
| Copyright © 2000 - 2009 MantisBT Group |
 |