Issue 55: Use a explicit Query for fetching the Submission Type list. #71
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relates #55
The test data consisted of randomly generated data with:
The submission list page took ~3.5 minutes to load the Submission Type list data.
Switching to an explicit query, the submission list page took ~320 milliseconds to load the Submission Type list data.
This is an overwhelming clear improvement that shows that the use of Spring+JPA internals are highly inefficient for the Field Values and related data.
For the filters, the actual model does not need to be loaded and only the value.
The use of a JDBC query is chosen after doing tests against Postgresql and H2.
The use of a native query via
@Query
worked for Postgresql but H2 used clob2 and failed to convert the results into strings.Using a literal query is chosen over a JPA query because the JPA wants to understand the model structure.
The Field Predicate is not loaded immediately available for JPA for the FieldValue JPA Repository.
Only very basic SQL is used in the query and so there should be very little SQL compatibility risks.
The biggest risk is that of the table naming structure.
This structure appears to be sufficiently consistent between Postgresql and H2 in this regard.
Spring+JPA Performance:
JDBC Performance: