Openbravo Issue Tracking System - Openbravo ERP | ||||||||||||
View Issue Details | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||||||
0033810 | Openbravo ERP | A. Platform | public | 2016-08-12 17:24 | 2016-08-29 15:12 | |||||||
Reporter | shuehner | |||||||||||
Assigned To | aferraz | |||||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | |||||||
Status | closed | Resolution | fixed | |||||||||
Platform | OS | 5 | OS Version | |||||||||
Product Version | ||||||||||||
Target Version | 3.0PR16Q2.3 | Fixed in Version | 3.0PR16Q2.3 | |||||||||
Merge Request Status | ||||||||||||
Review Assigned To | caristu | |||||||||||
OBNetwork customer | ||||||||||||
Web browser | ||||||||||||
Modules | Core | |||||||||||
Support ticket | ||||||||||||
Regression level | ||||||||||||
Regression date | ||||||||||||
Regression introduced in release | ||||||||||||
Regression introduced by commit | ||||||||||||
Triggers an Emergency Pack | No | |||||||||||
Summary | 0033810: Double query in PricelistVersionFilterExpression (product selector) | |||||||||||
Description | The PriceListVersionFilterExpression has following code which does 2 db queries OBCriteria<PriceListVersion> plVersionCrit = OBDal.getInstance().createCriteria( PriceListVersion.class); plVersionCrit.add(Restrictions.eq(PriceListVersion.PROPERTY_PRICELIST, priceList)); plVersionCrit.add(Restrictions.le(PriceListVersion.PROPERTY_VALIDFROMDATE, date)); if (plVersionCrit.count() > 0) { plVersionCrit.addOrderBy(PriceListVersion.PROPERTY_VALIDFROMDATE, false); return plVersionCrit.list().get(0); } Filter m_pricelist_version by m_pricelist_id and validfrom<='some value' First query does a count of matching rows. Then order by validfrom desc is added and a 2nd query is done to retrieve the 'newest' row. The count query is not really an optimization as it forces same effort on db. As there is a m_pricelist_id + name unique constraint those filter criteria combination is indexed anyway. Additionally that query should get a "limit 1" constraint as it only uses 1 row of result anyway. Without that and many pricelistversion matches the filter criteria lots of rows are loaded into memory without good reason. | |||||||||||
Steps To Reproduce | - | |||||||||||
Proposed Solution | ||||||||||||
Additional Information | ||||||||||||
Tags | No tags attached. | |||||||||||
Relationships |
| |||||||||||
Attached Files | ||||||||||||
Issue History | ||||||||||||
Date Modified | Username | Field | Change | |||||||||
2016-08-25 14:25 | aferraz | Type | defect => backport | |||||||||
2016-08-25 14:25 | aferraz | Target Version | => 3.0PR16Q2.3 | |||||||||
2016-08-29 13:09 | aferraz | Assigned To | shuehner => aferraz | |||||||||
2016-08-29 14:20 | hgbot | Checkin | ||||||||||
2016-08-29 14:20 | hgbot | Note Added: 0089497 | ||||||||||
2016-08-29 14:20 | hgbot | Status | scheduled => resolved | |||||||||
2016-08-29 14:20 | hgbot | Resolution | open => fixed | |||||||||
2016-08-29 14:20 | hgbot | Fixed in SCM revision | http://code.openbravo.com/erp/devel/pi/rev/8057375243880a2830c0537f24d037f675879b66 [^] => http://code.openbravo.com/erp/backports/3.0PR16Q2.3/rev/2cc93f8dd77a19d5de50d47f71ef46e941e49655 [^] | |||||||||
2016-08-29 15:12 | caristu | Note Added: 0089505 | ||||||||||
2016-08-29 15:12 | caristu | Status | resolved => closed | |||||||||
2016-08-29 15:12 | caristu | Fixed in Version | => 3.0PR16Q2.3 |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|