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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0033139
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajorhave not tried2016-06-05 15:122016-08-18 11:47
ReportershuehnerView Statuspublic 
Assigned Tomario_castello 
PrioritynormalResolutionfixedFixed in VersionRR16Q4
StatusclosedFix in branchFixed in SCM revision678425057c39
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toguilleaer
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0033139: OrderLoader: Inefficient check for m_locator doing 2-3 queries for the same

DescriptionOrderLoader is querying m_locator (for order.getWarehouse()) essentially up to 3 times

1.) just after 'if (createShipment)' to see if none are present and error out
2.) a few lines later in call to createShipment doing .count() to check if exactly one is present
3.) then just after that said count another .uniqueResult() to retrieve that 'exactly one'

All those can be done with a single sql.
Steps To ReproduceTrace SQL done by OrderLoader.
Proposed SolutionReplace all 3 calls by single query.

Adding simple .setMaxResults(2) and .list() gives us all the info we need and the limit 2 avoids ever reading >2 rows into memory.

Note: Even while only wanting .count()==1 and reading single row we need to use a limit of 2 to distinguish the count=1 or count>1 case.

As we only care about count being exactly 1 (or not) we do not need to do proper count for any values >1 to the limit 2 does the trick nicely.

TagsPerformance
Attached Filesdiff file icon 33139.diff [^] (2,601 bytes) 2016-06-05 15:13 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]
depends on backport 0033615RR16Q3.1 closedmario_castello Retail Modules OrderLoader: Inefficient check for m_locator doing 2-3 queries for the same 
depends on backport 0033616RR16Q2.2 closedRetail Retail Modules OrderLoader: Inefficient check for m_locator doing 2-3 queries for the same 
has duplicate defect 0033619 closedRetail Retail Modules Slow order loader process when there are thousends of locators for one warehouse 
related to defect 0033627 closedmtaal Openbravo ERP debug call in OBCriteria.count does trigger extra db query in some case 
blocks defect 0033732RR16Q4 closedguilleaer Retail Modules [API change] Reuse Locator List Informationin createShipmentLines 

-  Notes
(0087003)
shuehner (administrator)
2016-06-05 15:14

NOTE: The attached patch does an API change as the method createShipmentLines is protected (so part of API).
(0088822)
hgbot (developer)
2016-08-04 16:05

Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 678425057c397e1f5ac3c7ca65244227cbbeb84a
Author: Mario Castello <mario.castello <at> peoplewalking.com>
Date: Wed Aug 03 14:28:43 2016 -0600
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/678425057c397e1f5ac3c7ca65244227cbbeb84a [^]

Fixed issue 33139: Replace the sames query for m_locator in orderloader class for only one query

---
M src/org/openbravo/retail/posterminal/OrderLoader.java
---
(0089123)
mtaal (manager)
2016-08-16 10:27

Hi,
Officially this is an api change which is not backward compatible by changing the signature of the protected method.

An api change needs to be approved by dmitry (just drop him an email with the link to this issue) and then add it on this page:
http://wiki.openbravo.com/wiki/Retail:API_changes [^]

In the PI section.

gr. Martin
(0089207)
guilleaer (manager)
2016-08-18 11:46

API check approved

https://issues.openbravo.com/view.php?id=33732 [^]

Added to API changes wiki page

http://wiki.openbravo.com/wiki/Retail:API_changes [^]
(0089208)
guilleaer (manager)
2016-08-18 11:47

Closed and Reviewed. API change approved

- Issue History
Date Modified Username Field Change
2016-06-05 15:12 shuehner New Issue
2016-06-05 15:12 shuehner Assigned To => Retail
2016-06-05 15:12 shuehner Triggers an Emergency Pack => No
2016-06-05 15:13 shuehner File Added: 33139.diff
2016-06-05 15:14 shuehner Note Added: 0087003
2016-06-05 15:14 shuehner Tag Attached: Performance
2016-08-03 14:26 marvintm Severity minor => major
2016-08-03 14:26 marvintm Status new => scheduled
2016-08-03 15:54 egoitz Relationship added has duplicate 0033619
2016-08-03 22:38 mario_castello Assigned To Retail => mario_castello
2016-08-04 16:05 hgbot Checkin
2016-08-04 16:05 hgbot Note Added: 0088822
2016-08-04 16:05 hgbot Status scheduled => resolved
2016-08-04 16:05 hgbot Resolution open => fixed
2016-08-04 16:05 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/678425057c397e1f5ac3c7ca65244227cbbeb84a [^]
2016-08-04 17:21 shuehner Relationship added related to 0033627
2016-08-10 10:02 migueldejuana Review Assigned To => mtaal
2016-08-16 10:27 mtaal Note Added: 0089123
2016-08-16 10:27 mtaal Status resolved => new
2016-08-16 10:27 mtaal Resolution fixed => open
2016-08-17 17:20 mario_castello Status new => acknowledged
2016-08-17 19:08 guilleaer Relationship added blocks 0033732
2016-08-18 11:46 guilleaer Note Added: 0089207
2016-08-18 11:46 guilleaer Status acknowledged => scheduled
2016-08-18 11:47 guilleaer Status scheduled => resolved
2016-08-18 11:47 guilleaer Fixed in Version => RR16Q4
2016-08-18 11:47 guilleaer Resolution open => fixed
2016-08-18 11:47 guilleaer Review Assigned To mtaal => guilleaer
2016-08-18 11:47 guilleaer Note Added: 0089208
2016-08-18 11:47 guilleaer Status resolved => closed


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker