wog48
commented
5 years ago The JPA Processor is not using named queries. It generates criteria queries. This is because OData is very flexible and allows filtering on every property and allows to use a variety of operators and in-build functions. This flexibility shall be offered.
Even if you would give the user of the frame work the opportunity to restrict the options via additional annotations, a pure usage of named queries would require that for each combination of supported filterable property and supported operation/in-build function a named query must be created upfront. This would end-up in a big number of named queries and a lot of effort or a minimum of flexibility on the consumer site.
In case you don't have a microservice architecture and see that you get a bigger number of the same requests for a rarely changing entity and the DB cache is not suffisant from a performance perspective, it may makes sense to create a cache, which stores the serialized result. This is because one can save conversion and serialization effort as well.
You can perform simple performance measurement by adding a debugger to the request context:
handler.getJPAODataRequestContext().setDebugSupport(new DefaultDebugSupport());
and add odata-debug=html to the URL. In case you followed the tutorials you may want to try
.../AdministrativeDivisions?odata-debug=html
e.g. /user?filter=... would result in a named JPAQuery object with name "query-user", /user/company . would result in a named JPAQuery object with name "query-company-from-user.
Because EclipseLink query cache only works for named query, so all the queries better be named.