0022553: sqlc.queryExecutionStrategy=optimized not applied in modules

Description

Optimized 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 Reproduce

In 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 Solution

In 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.

Tags

Performance

Attached Files

Relationships [ Relation Graph ] [ Dependency Graph ]

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.

Notes
(0054911) alostale (manager) 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 (administrator) 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 (developer) 2013-03-01 20:12	Let´s put target version when we are sure we can deliver.

Issue History
Date Modified	Username	Field	Change
2012-12-13 10:12	alostale	New Issue
2012-12-13 10:12	alostale	Assigned To	=> AugustoMauch
2012-12-13 10:12	alostale	Modules	=> Core
2012-12-13 10:12	alostale	Triggers an Emergency Pack	=> No
2012-12-13 10:12	alostale	Relationship added	related to 0004038
2012-12-13 10:12	alostale	Tag Attached: Performance
2012-12-13 10:19	alostale	Note Added: 0054911
2012-12-13 10:58	shuehner	Note Added: 0054912
2012-12-13 11:07	shuehner	Relationship added	related to 0022559
2013-02-04 09:53	AugustoMauch	Target Version	3.0MP20 => 3.0MP21
2013-03-01 20:12	dmitry_mezentsev	Note Added: 0056909
2013-03-01 20:12	dmitry_mezentsev	Target Version	3.0MP21 =>