Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0049691 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Openbravo Localizations] Localization France | major | always | 2022-06-29 22:50 | 2023-03-20 13:34 | |||
| Reporter | egoitz | View Status | public | |||||
| Assigned To | egoitz | |||||||
| Priority | urgent | Resolution | duplicate | Fixed in Version | ||||
| Status | closed | Fix in branch | Fixed in SCM revision | |||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Regression date | ||||||||
| Regression introduced by commit | ||||||||
| Regression level | ||||||||
| Regression introduced in release | ||||||||
| Summary | 0049691: Some queries are slow, and read lot of information from disk on environment with millioins of transation. | |||||||
| Description | There are some queries related to the french localization and the fiscal certification that are creating high disk usage /contention on environments with million of records. There quereis are the following and other similar in the other tables tables. select distinct obcfr_tick0_.Obpos_Applications_ID as col_0_0_ from OBCFR_Ticket obcfr_tick0_ where obcfr_tick0_.AD_Client_ID='??'; Executed by openbravo=> select distinct obcfr_tick0_.Obpos_Applications_ID as col_0_0_ from OBCFR_Ticket obcfr_tick0_ where obcfr_tick0_.AD_Client_ID='757D621ABD1948F5BCBAD91F19BB70AC'; That is happening even having the following patches applied: https://gitlab.com/openbravo/ci/modules/org.openbravo.certification.france.dev/-/commit/cc55b8f1f4bb8212985b330518684ba19508f114 [^] | |||||||
| Steps To Reproduce | Check database statistics. Execute the query on an environmnent with million of records in the table. | |||||||
| Proposed Solution | Could be an option to check the terminals with blockchain initialized ( maybe + last order sync not null) to get the same value? | |||||||
| Tags | NOR | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|||||||||||||||||
|
|||||||||||||||||
 Relationships |
|
Notes |
|
|
(0139637) aferraz (developer) 2022-07-27 11:06 |
We are waiting for a test environment where the problem is reproduced. It's likely that the problem is fixed by applying 0047331. |
|
(0139651) sebastien_liron (reporter) 2022-07-27 16:02 |
as per victor : Please note we haven't transplanted yet to pmods; we will do it in several weeks as part of the preparation for the new certification process (which will take place in one month's time). It does not seems to me that the MR was done on the standard module |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2022-06-29 22:50 | egoitz | New Issue | |
| 2022-06-30 09:19 | psanjuan | Assigned To | => aferraz |
| 2022-06-30 09:19 | psanjuan | Summary | Some queries are slow are read lot of information from disk on environment with millioins of transation. => Some queries are slow, and read lot of information from disk on environment with millioins of transation. |
| 2022-07-12 17:30 | aferraz | Assigned To | aferraz => igor_trebol |
| 2022-07-13 08:53 | egoitz | Issue cloned | 0049792 |
| 2022-07-13 08:53 | egoitz | Relationship added | related to 0049792 |
| 2022-07-13 09:45 | rafaroda | Tag Attached: NOR | |
| 2022-07-25 12:41 | sebastien_liron | Issue Monitored: sebastien_liron | |
| 2022-07-27 11:05 | aferraz | Assigned To | igor_trebol => egoitz |
| 2022-07-27 11:06 | aferraz | Note Added: 0139637 | |
| 2022-07-27 11:06 | aferraz | Status | new => feedback |
| 2022-07-27 16:02 | sebastien_liron | Note Added: 0139651 | |
| 2023-03-20 13:34 | aferraz | Relationship added | duplicate of 0047331 |
| 2023-03-20 13:34 | aferraz | Status | feedback => closed |
| 2023-03-20 13:34 | aferraz | Resolution | open => duplicate |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |