Project:
| View Revisions: Issue #34669 | [ Back to Issue ] | ||
| Summary | 0034669: ProcessHQLQuery returns duplicates causing errors when inserting data and really slow login with many products | ||
| Revision | 2016-12-01 16:43 by mtaal | ||
| Steps To Reproduce | Create a database which would return products for all product queries in the product master Set the limit in the request for products to something small - Find this line: handleIncrementalRequest(35000, 0, params, incremental); and change it to: handleIncrementalRequest(20, 0, params, incremental); clear cache and log in --> duplicate errors |
||
| Revision | 2016-12-01 16:43 by mtaal | ||
| Description | The ProcessHQLQuery class uses the offset and limit parameters to support paginated data [1]. This is needed in case of large datasets so that the client side is not flooded with too much data. The ProcessHQLQuery class can execute multiple queries depending on the subclass implementation. It will change the offset/limit after each query [2]. For 2 examples see the Product [3] and Business Partner [4]. The problem is that if there are multiple queries then these queries will use different offset/limit parameters within one request. This means that the next request for the next page will get overlapping data with previous requests or can skip data. Let's take an example: Subclass of ProcessHQLQuery adds 2 queries. The first query would return 15000 records (unpaginated), the second query would return 8000 records (unpaginated). Master data load: Request 1: offset: 0, limit: 10000 With the current code this would return only 10000 records of the first query, the second query won't be executed anymore Request 2: offset: 10000, limit: 10000 This would return 5000 records of the first query and the first 5000 records of the second query (the offset is set to zero if a query returns less than the limit). Request 3: offset: 20000, limit: 10000 This would return the first 8000 records of the second query, overlapping with request 2 [1] https://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/file/0d7bcfc60eb8/src/org/openbravo/mobile/core/process/ProcessHQLQuery.java#l165 [^] [2] https://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/file/0d7bcfc60eb8/src/org/openbravo/mobile/core/process/ProcessHQLQuery.java#l229 [^] [3] https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/file/5754a065bc58/src/org/openbravo/retail/posterminal/master/Product.java#l247 [^] https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/file/5754a065bc58/src/org/openbravo/retail/posterminal/master/Product.java#l271 [^] https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/file/5754a065bc58/src/org/openbravo/retail/posterminal/master/Product.java#l301 [^] [4] https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/file/5754a065bc58/src/org/openbravo/retail/posterminal/master/BusinessPartner.java#l57 [^] |
||
| Revision | 2016-12-01 16:38 by mtaal | ||
| Steps To Reproduce | Create a database which would return products for all product queries in the product master Set the limit in the request for products to something small - Find this line: handleIncrementalRequest(35000, 0, params, incremental); and change it to: handleIncrementalRequest(20, 0, params, incremental); clear cache and log in |
||
| Revision | 2016-12-01 16:38 by mtaal | ||
| Description | The ProcessHQLQuery class uses the offset and limit parameters to support paginated data [1]. This is needed in case of large datasets so that the client side is not flooded with too much data. The ProcessHQLQuery class can execute multiple queries depending on the subclass implementation. For 2 examples see the Product [3] and Business Partner [4]. The problem is that if there are multiple queries then these queries will use different offset/limit parameters within one request. This means that the next request for the next page will get overlapping data or can skip data. Let's take an example: >>>>>>> Example skipping records: Subclass of ProcessHQLQuery adds 2 queries. The first query would return 15000 records (unpaginated), the second query would return 8000 records (unpaginated). Master data load: Request 1: offset: 0, limit: 10000 With the current code this would return only 10000 records of the first query, the second query won't be executed anymore Request 2: offset: 10000, limit: 10000 This would return 5000 records of the first query and the first 5000 records of the second query (the offset is set to zero if a query returns less than the limit). Request 3: offset: 20000, limit: 10000 This would return the first 8000 records of the second query, overlapping with request 2 |
||
| Copyright © 2000 - 2009 MantisBT Group |
 |