Openbravo Issue Tracking System - Openbravo ERP | |||||
View Issue Details | |||||
ID | Project | Category | View Status | Date Submitted | Last Update |
0056426 | Openbravo ERP | Z. Others | public | 2024-09-10 16:01 | 2024-10-04 16:19 |
Reporter | william_vermersch | ||||
Assigned To | kousalya_r | ||||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Platform | OS | 5 | OS Version | ||
Product Version | |||||
Target Version | Fixed in Version | PR25Q1 | |||
Merge Request Status | |||||
Review Assigned To | |||||
OBNetwork customer | |||||
Web browser | |||||
Modules | Core | ||||
Support ticket | |||||
Regression level | |||||
Regression date | |||||
Regression introduced in release | |||||
Regression introduced by commit | |||||
Triggers an Emergency Pack | No | ||||
Summary | 0056426: Computed column in Financial Account screen is not optimized (screen is taking a long time to load) | ||||
Description | The column "last reconciliation balance" is making the screen really long to load when you have a lot of reconciliations linked to you financial accounts. | ||||
Steps To Reproduce | Have a lot of reconciliations on one (or more) financial accounts. Go to the Financial Account screen. | ||||
Proposed Solution | It seems that using the "HAVING" in the query computing the value is the cause of the issue (column "9DA1E5CA5A25476C9764CCBEC70E3E36"). Original query: select max(rec.endingbalance) from fin_reconciliation rec where rec.fin_financial_account_id = fin_financ0_.fin_financial_account_id and exists ( select 1 from fin_reconciliation fr where fr.processed = 'Y' and fr.fin_financial_account_id = fin_financ0_.fin_financial_account_id having rec.dateto = max(fr.dateto) ) Potential optimization (running in ms, instead of s): select max(rec.endingbalance) from fin_reconciliation rec where rec.fin_financial_account_id = fin_financ0_.fin_financial_account_id and rec.dateto = ( select max(fr.dateto) from fin_reconciliation fr where fr.processed = 'Y' and fr.fin_financial_account_id = fin_financ0_.fin_financial_account_id ) I checked in production (for our Weldom customer) and the result were the same for the 2 queries, the first one was taking more than 4 minutes and the second one less than one second. I'm not sure at 100% that the 2 queries are identical, I'll let you review if it can be an accepted solution. | ||||
Additional Information | |||||
Tags | No tags attached. | ||||
Relationships | |||||
Attached Files | |||||
Issue History | |||||
Date Modified | Username | Field | Change | ||
2024-09-10 16:01 | william_vermersch | New Issue | |||
2024-09-10 16:01 | william_vermersch | Assigned To | => Triage Omni OMS | ||
2024-09-10 16:01 | william_vermersch | Modules | => Core | ||
2024-09-10 16:01 | william_vermersch | Triggers an Emergency Pack | => No | ||
2024-10-01 15:35 | jonae | Note Added: 0169851 | |||
2024-10-01 15:36 | jonae | Assigned To | Triage Omni OMS => kousalya_r | ||
2024-10-03 12:08 | hgbot | Note Added: 0169948 | |||
2024-10-04 13:16 | hgbot | Resolution | open => fixed | ||
2024-10-04 13:16 | hgbot | Status | new => closed | ||
2024-10-04 13:16 | hgbot | Fixed in Version | => PR25Q1 | ||
2024-10-04 13:16 | hgbot | Note Added: 0170004 | |||
2024-10-04 13:16 | hgbot | Note Added: 0170005 | |||
2024-10-04 14:56 | hgbot | Note Added: 0170015 | |||
2024-10-04 16:19 | hgbot | Note Added: 0170017 | |||
2024-10-04 16:19 | hgbot | Note Added: 0170018 |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|