JPA: NoGo for Teradata or ok with the following rules...?

Connectivity
Teradata Employee

JPA: NoGo for Teradata or ok with the following rules...?

Hi all,

our customer is building a mobile application and is requesting our ok for them using JPA.

Here are the rulse they are sugesting to make it work in a performant manner. Is there anyone out there who could review them and point us pitfalls / problems that could arise from JPA usage...

We have developed few sample flows using JPA for processing OData requests  last week and also did some testing on how the queries gets generated for different requests. We had to write some custom code to build an optimized JPQL / Criteria based on the user request. We following some strict rules while defining the JPA entities to avoid the problem of firing many small queries (N+1 SELECTs problem). We also restricted the number of/joins in queries, same as if we were using native queries directly to implement the same functionality. With these changes the performance was similar to that of using native queries.

These are the rules/customization we did to avoid the small queries:

1.       Marked all associations (i.e., OneToMany, ManyToOne, OneToOne) as  lazy, so they will not be fetched unless it is overridden for specific queries. The custom code builds the optimized JPQL with appropriate joins (overriding the laziness) depending on user request, so that all the data is fetched in a single shot and there is no need to load any lazy associations later.

2.       We are restricting the expands to OneToOne and ManyToOne associations only. Any request from user for expanding OneToMany associations will be rejected.

3.       Suppose that a certain request can be performed better by using native query and  the same cannot be done using JPA, the developer has always an option to provide his own implementation. The developer will proactively check the queries generated by JPA so that he can override it whenever required.

4.       We may not use the JPA based approach for inserts/updates (and only use it for selects and deletes) if it involves more than one table. There is no JPA code to achieve this as of now, so the developer will have to provide his implementation with native queries as earlier.

5.       The custom implementation also takes care of pagination and count queries using JPA. A custom Dialect class for Teradata to generate query the correct ‘order by’ syntax is developed to support this.

The main motivation for moving to JPA is that, we will be saving a lot of developer effort and avoiding bugs with this implementation for OData services. Please let me know if you have any other concerns which I haven’t addressed here. We can also share with you the application logs/url to verify the queries.

Many thanks in advance,

Martin