Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0033524 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
backport | [Retail Modules] Web POS | major | sometimes | 2016-07-21 11:20 | 2016-08-04 12:00 | |||
Reporter | marvintm | View Status | public | |||||
Assigned To | ranjith_qualiantech_com | |||||||
Priority | normal | Resolution | fixed | Fixed in Version | ||||
Status | closed | Fix in branch | Fixed in SCM revision | 990ac1cac5e0 | ||||
Projection | none | ETA | none | Target Version | RR16Q2.2 | |||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Review Assigned To | marvintm | |||||||
Regression level | ||||||||
Regression date | ||||||||
Regression introduced in release | ||||||||
Regression introduced by commit | ||||||||
Triggers an Emergency Pack | No | |||||||
Summary | 0033524: Masterdata loading fails when pagination happens | |||||||
Description | The Web POS loads masterdata models using pagination, which means that if there are many records (currently, more than 35000) in a given model, the first 35000 will be loaded, and then the next 35000, and so on, until all of them are loaded. Currently, this mechanism is failing in some cases, so that if there are more than 35000 records in a model, some of them are not loaded in the Web POS. | |||||||
Steps To Reproduce | There are two ways to reproduce the problem: - Find a database with many records (more than 35000 in one model). Log in the Web POS, and verify that not all records are in the local database. An easier way (and advisable for the developer who will be fixing the problem) is the following: - Log in the Web POS, go to Chrome Developer Tools, and execute the query in the local database: select count(*) from m_product Verify that there are 164 records in the table. - Then, go to file ob-datasource.js. - Find this line: handleIncrementalRequest(35000, 0, params, incremental); and change it to: handleIncrementalRequest(20, 0, params, incremental); - Clear cache and log in the Web POS again. - Execute the same query in the local database. Verify that there are 162 products. There were two products lost at some point, and this is wrong. | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | ||||||||
|
Notes | |
(0088666) hgbot (developer) 2016-07-26 13:01 |
Repository: retail/backports/3.0RR16Q2.2/org.openbravo.mobile.core Changeset: 990ac1cac5e0b5bf33b4454ff68b709409aa94e5 Author: Ranjith S R <ranjith <at> qualiantech.com> Date: Tue Jul 26 16:27:23 2016 +0530 URL: http://code.openbravo.com/retail/backports/3.0RR16Q2.2/org.openbravo.mobile.core/rev/990ac1cac5e0b5bf33b4454ff68b709409aa94e5 [^] Fixes issue 33524 : Reset hqlquery offset if the model has multiple queries - for a model which has multiple queries, hqlquery offset value has to be resetted if last query counted rows doesn't exceed the limit rows --- M src/org/openbravo/mobile/core/process/ProcessHQLQuery.java --- |
Issue History | |||
Date Modified | Username | Field | Change |
2016-07-21 12:38 | Orekaria | Type | defect => backport |
2016-07-21 12:38 | Orekaria | Target Version | => RR16Q2.2 |
2016-07-26 11:54 | ranjith_qualiantech_com | Assigned To | Retail => ranjith_qualiantech_com |
2016-07-26 13:01 | hgbot | Checkin | |
2016-07-26 13:01 | hgbot | Note Added: 0088666 | |
2016-07-26 13:01 | hgbot | Status | scheduled => resolved |
2016-07-26 13:01 | hgbot | Resolution | open => fixed |
2016-07-26 13:01 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/retail/backports/3.0RR16Q2.2/org.openbravo.mobile.core/rev/990ac1cac5e0b5bf33b4454ff68b709409aa94e5 [^] |
2016-08-04 12:00 | marvintm | Review Assigned To | => marvintm |
2016-08-04 12:00 | marvintm | Status | resolved => closed |
Copyright © 2000 - 2009 MantisBT Group |