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 | approved | ||||
| Review Assigned To | |||||
| OBNetwork customer | Gold | ||||
| Web browser | |||||
| Modules | Core | ||||
| Support ticket | 108503 | ||||
| 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 | OBNetwork customer | => Gold | ||
| 2024-09-10 16:01 | william_vermersch | Modules | => Core | ||
| 2024-09-10 16:01 | william_vermersch | Support ticket | => 108503 | ||
| 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 | Merge Request Status | => open | ||
| 2024-10-03 12:08 | hgbot | Note Added: 0169948 | |||
| 2024-10-04 13:16 | hgbot | Merge Request Status | open => approved | ||
| 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 | |||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||