I’m a longtime NHibernate user on the .NET platform who has recently made the leap to Java/Hibernate. In looking at my company’s source code and in Hibernate examples I’ve seen, it seems to be the norm to have hard-coded HQL or SQL strings. In my experience with NHibernate, it was more common to use type-safe APIs (LINQ most commonly, but a fluent query API was available as well).
This seems counter-intuitive to me, as Hibernate is more mature than NHibernate, as is Java. I would think that hard-coded HQL/SQL would be considered sub-optimal for obvious reasons.
Have I gotten the wrong idea, and are strongly-typed queries the norm in Hibernate?
HQL is strongly typed as well, it’s just not compile time checked. If you use named queries though, such queries can be checked/compiled during application boot.
Query strings are usually very good if they fit your needs as they are a perfect cache key for Hibernate to cache the translation. If you use JPA Criteria or the Hibernate extensions to it, which is for dynamic queries e.g. dynamic filters/sorting etc., every execution will translate again. The translation is pretty fast, especially in Hibernate 6, but there is still some “latency” due to it, which can ultimately be avoided by reusing/caching that translation. Since the very nature of dynamic queries is that they are dynamic, the query plans for them usually aren’t cache though because we’d need to build some kind of cache key based on the contents, which kind of defeats the purpose as we’d have to “traverse” the query model an additional time, which leads to some latency again.