Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0005365Openbravo ERPI. Performancepublic2008-10-01 17:582009-01-29 18:24
opablo 
shuehner 
urgentminoralways
closedno change required 
5
2.40 
 
Core
No
0005365: Under some circumstances, DataGrid performs two identical queries to retrieve the data
When the number of registers of a DataGrid is less than a screen, to fill the DataGrid, two identical requests are issued. Seems that valid data from first request are discarded, and data from second request (same results than the first one) is actually showed in DataGrid.

We see the 2 requests in the server's access log:
127.0.0.1 - - [01/Oct/2008:17:57:16 +0200] "POST /openbravo/utility/DataGrid.html?Command=DATA&inpadTabId=180&inpadWindowId=140&inpAccessLevel=3 HTTP/1.1" 200 689
127.0.0.1 - - [01/Oct/2008:17:57:16 +0200] "POST /openbravo/utility/DataGrid.html?Command=DATA&inpadTabId=180&inpadWindowId=140&inpAccessLevel=3 HTTP/1.1" 200 689

If DataGrid has 0 records, or more records than a screen, only one request is issued to retrieve data.

This behaviour has been tested under Firefox 2.0 and IE 6.0, and occurs in 2.35 and 2.40
Navigate to:
Master Data Management > Product > Grid View

or

General Setup > Application > Currency > Search Records > ISO Code: ESP > OK
No tags attached.
related to feature request 0007242 closed shuehner Optimize DataGrid fetch logic to use one bigger request instead of two distinct small request 
depends on backport 0005366 closed shuehner Under some circumstances, DataGrid performs two identical queries to retrieve the data 
Issue History
2008-10-01 17:58opabloNew Issue
2008-10-01 17:58opabloAssigned To => cromero
2008-10-01 17:58opablosf_bug_id0 => 2140621
2008-10-01 18:05cromeroStatusnew => scheduled
2008-10-01 18:05cromeroAssigned Tocromero => shuehner
2008-10-01 18:05cromerofix_in_branch => trunk
2008-10-02 09:48opabloIssue Monitored: opablo
2008-10-02 13:58pjuvaraPrioritynormal => high
2008-10-30 15:15pjuvaraPriorityhigh => immediate
2008-11-07 08:57pnudingNote Added: 0010059
2008-11-07 08:57pnudingPriorityimmediate => urgent
2008-11-07 08:57pnudingfix_in_branchtrunk =>
2008-11-27 11:20svnbotCheckin
2008-11-27 11:20svnbotNote Added: 0010762
2008-11-27 11:20svnbotStatusscheduled => resolved
2008-11-27 11:20svnbotResolutionopen => fixed
2008-11-27 11:20svnbotsvn_revision => 10660
2009-01-28 16:45psarobeStatusresolved => new
2009-01-28 16:45psarobeResolutionfixed => open
2009-01-28 16:45psarobeNote Added: 0012753
2009-01-29 18:18shuehnerRelationship addedrelated to 0007242
2009-01-29 18:24shuehnerRegression testing => No
2009-01-29 18:24shuehnerStatusnew => closed
2009-01-29 18:24shuehnerNote Added: 0012854
2009-01-29 18:24shuehnerResolutionopen => no change required

Notes
(0010059)
pnuding   
2008-11-07 08:57   
Issue is scheduled for resolution in Sprint 3 of the Performance project - as discussed with PJuvara reduced priority to urgent to avoid confusion
(0010762)
svnbot   
2008-11-27 11:20   
Repository: openbravo
Revision: 10660
Author: iperdomo
Date: 2008-11-27 11:20:51 +0100 (Thu, 27 Nov 2008)

Fixes issue 5365: Added reduced the pageSize to the number of available rows, to prevent the double request

---
U trunk/web/js/openbravo/widget/DataGrid.js
---

https://dev.openbravo.com/websvn/openbravo/?rev=10660&sc=1 [^]
(0012753)
psarobe   
2009-01-28 16:45   
This was committed in trunk + r2.40 but later thrown out again as it had some side-effects (errors).
(0012854)
shuehner   
2009-01-29 18:24   
We did verify the bug and the datagrid does not request the same data twice and does not discard one of the answers.
This is not directly visible as the interesting parameters are transmitted as post parameters and not visible in the request-url.
When looking at the post parameters it can be seen that the DataGrid.js does request two non-overlapping regions which are centered around the targeted line/offset. This is done to request not only the visible records but also the page before and after the visible records to be able to scroll for one page before requesting new data again.

Thus this issue not as is not valid as two different, adjecent record-range are requested and both are used on the client side.
This is the reason for closing this defect.

However we opened a new feature request (0007242), as using a single bigger request two fetch both regions in one batch will probably/likely improve the performance.