JPA Criteria is one of the most awkward API-s I have to use on daily basis. I can’t even remember how a single thing has to be done with this API and I constantly have to refer to the docs. First it’s because they involved a lot of objects in the process, like: EntityManager
, CriteriaBuilder
, Root
entity, CriteriaQuery
which then should be converted to TypedQuery
. About all those things you have to think about where to get them from and how to use them together to build a query. Secondly, because this API expects everywhere to get abstract interfaces, like Selection
or Predicate
with no single line of documentation how to create concrete instances of these classes, and you usually have to review large CriteriaBuilder
interface to find what you want. However, writing recently in Kotlin, I’ve found some optimizations given by this language you can use to make things less abstruse.
Working recently with Hibernate batch processing I’ve followed the default pattern promoting callings session.clear()
periodically. In this article I’m going to describe what problems can be caused by this approach and how to avoid them.
MySQL as well as other SQL databases doesn’t return data in a predictable order without using order by
clause. This can be a problem in some situations: for example user adding positions to an invoice can expect they’re returned in the same order from the server. The same expectation is possibly true for the most of other master-detail use cases. In this short example I’m going to show a simple trick how to achieve this.
Micronaut is a brand-new framework from Grails creators targeted to be a first choice for microservices architecture framework in Java world and the as the main Spring Boot competitor, while GraphQL is becoming recently more and more popular standard to query backend data with JSON. In this article I’m going to show how to glue both technologies to provide a complete foundation on which one can build his own Hibernate/JPA application.
Read the full articleWe have been thinking recently about using some SQL views in our Hibernate application backed by postgresql. It looks feasible and even it enables great possibilities. Below quick snapshot from my testing app showing how it works.
Read the full articleHibernate provides an option to lazy fetch single-sided (to-one) associations using lazy proxy or bytecode instrumentation. However, both approaches suffer some problems. Byte code instrumentation … requires byte code instrumentation, while lazy proxies can be really problematic regarding type casting and instanceof
check especially in existing systems and framewors. But don’t worry. In few words below I’ll describe a solution I’ve figured out for the existing system to improve performance using lazy to-one overcoming casting problems and not using instrumentation.
This article will be about multiple joins in Hibernate model during super class fetch in JOINED inheritance mapping strategy, and generally how I significantly improved our system performance using some simple patterns. There’s a lot of stuff on internet about this (usually wrong approach), so here I’ll present my working solution for this problem.
Read the full articleFew days ago I was asked to implement charts with some finance data using JS charting library, in the application working on Postgres database. There’s a lot of finance stuff in the database stored every minute and I just needed to show this data on charts.
OK, but charts are nice if you can restrict amount of your data returned from the server to some limited number of items. Returning 1000 items would both - make chart very heavy and unreadable and consume a lot of net traffic. I assumed 50 as the average number of items that are nicely displayed on such charts and are also acceptable from the traffic point of view.
Read the full articleThis catching title will be not about distributed hibernate search, but something really close :)
The case I’ve recently solved was a quite different. I have a frontend application that uses hibernate database and hibernate search, and then I needed to add additional application - let’s call it an integration server, which exposes some API webservices for the overall system. Integration server uses the same database as the frontend application, and enables clients to put data to the database using its webservices. Both applications exist on two different physical servers, as well.
Read the full articleIn previous BIRT versions there were three ways to use BIRT with your Hibernate datasource:
Previously I’ve been using plain SQL, but with complex database model it becomes very difficult (a lot of properties, joins and other relationships). Scripting data source using javascript is a bit too awkward for me, and certainly adds another level of application complexity, and another level of layers where “the things may go wrong”. Finally, Hibernate ODA data source from JBoss tools - this is what I wanted to use in older times, when I was using Eclipse, but for plain no-jboss application there were a lot of problem with these tools. They seem to be related to SEAM. Anyway AFAIR I had more problems with maintaining proper hibernate configuration in Eclipse (especially that it was partially annotation, and partially XML based) than the value of having working hibernate queries in IDE.
Read the full article