Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0022553Openbravo ERPA. Platformpublic2012-12-13 10:122013-03-01 20:12
Reporteralostale 
Assigned ToAugustoMauch 
PriorityurgentSeveritymajorReproducibilitysometimes
StatusnewResolutionopen 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0022553: sqlc.queryExecutionStrategy=optimized not applied in modules
DescriptionOptimized queryExecutionStrategy allows to improve performance when generating sqlc files in databases with big volumes of data. This is set by a parameter, but when it was implemented (2.50MP8), it was decided not to apply this optimization to modules (see commit comments "Enable for processing src/ folder. Disable by default for srcAD/ and modules/ to not impose stricter requirements on modules." https://code.openbravo.com/erp/devel/pi/rev/98441eb8254257a1db8f4334072719c16caf3f99 [^]).

The problem is most of the developments in real instances are not in core's src but spread in different modules, makes this optimization useless.

Steps To ReproduceIn an instance with big volume of data and custom modules installed and defaulted to do the optiomization (sqlc.queryExecutionStrategy=optimized in Openbravo.properties), do a compile complete. Note in log this line is shown when generating sqlc for modules:

[main] INFO org.openbravo.data.Sqlc - QueryExecutionStrategy: traditional

meaning that the optimization is not applied. Depending on the customizations it has it can last several minutes to complete.
Proposed SolutionIn addition to current sqlc.queryExecutionStrategy property in Openbravo.properties, a new one should be added to indicate whether previous one should also be applied to modules.

TBD: Should this new property be enabled by default? Some research on how modules might fail should be done before enabling by default.
Additional Information
TagsPerformance
Relationships
related to defect 0004038 closed shuehner Slow compilation in sqlC part due to high amount of data 
related to feature request 0022559 closed shuehner SqlC does execute all queries at compile time, which is not required. 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-12-13 10:12alostaleNew Issue
2012-12-13 10:12alostaleAssigned To => AugustoMauch
2012-12-13 10:12alostaleModules => Core
2012-12-13 10:12alostaleTriggers an Emergency Pack => No
2012-12-13 10:12alostaleRelationship addedrelated to 0004038
2012-12-13 10:12alostaleTag Attached: Performance
2012-12-13 10:19alostaleNote Added: 0054911
2012-12-13 10:58shuehnerNote Added: 0054912
2012-12-13 11:07shuehnerRelationship addedrelated to 0022559
2013-02-04 09:53AugustoMauchTarget Version3.0MP20 => 3.0MP21
2013-03-01 20:12dmitry_mezentsevNote Added: 0056909
2013-03-01 20:12dmitry_mezentsevTarget Version3.0MP21 =>

Notes
(0054911)
alostale   
2012-12-13 10:19   
In some real customer instance compile.complete (mp7.1 so all 2.50 windows are still generated) is reduced 42% from 15:30min to 6:30min.
(0054912)
shuehner   
2012-12-13 10:58   
Hi,
this was chosen to be traditional (slow) for modules and srcAD code as it will break some xsql file, it will not work for all existing files.

But we could do the following:
Enhacnce SqlC a bit: first try each XsqlMethod with the fast method, if we get some sql error, catch that silently and then re-try with the slow but safer method. Only if that also fails report the error (needed for broken xsql)

That way we get fast by default, but should get all sql still working without any extra user interaction.
(0056909)
dmitry_mezentsev   
2013-03-01 20:12   
Let´s put target version when we are sure we can deliver.