Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

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
Powered by Mantis Bugtracker