Mapping collections in Entity Views
09 May 2017
In the last post I have shown an introductory example of subviews to map singular associations. This time I will show how to map collections and how you can combine the powers of collections and subviews.
It is quite often necessary to load collections of data associated to an element. With plain JPA the normal way of doing this
is to query the entity type and to do a
JOIN FETCH of the *ToMany association. This works fine in the beginning,
but quickly falls apart when more collections or sub-associations of a collection are needed for similar use cases. By trying to avoid code duplication,
developers start adding
JOIN FETCH clauses to an existing query just so they can "reuse" the base query logic for other areas of an application.
Sometimes they forget to add a
JOIN FETCH and that results either in a
LazyInitializationException or in the N + 1 queries problems depending on the scope of the
JPAs answer to the code reuse problem is the ..
Entity View subview as rescue for LazyInitializationException
17 February 2017
In the last post I have introduced the basics of Entity Views.
This time I will show how subviews can be used to overcome the infamous
LazyInitializationException and N + 1 queries problems.
Nearly everyone who used JPA in his career already had the pleasure to experience problems associated with lazy initialization.
Depending on the persistence provider (Hibernate, EclipseLink, etc.), the outcome of a lazy initialization might differ due to
different default behaviors. Hibernate, for example, chooses to perform lazy initialization only on managed entity instances by default and
LazyInitializationException when it attempts to initialize an unmanaged entity.
On the other hand, EclipseLink’s default behavior is to allow lazy initialization of unmanaged entities as well by opening a transient connection for the loading.
The problem with lazy initialization is that ..
Displaying database contained data in tables is a basic requirement in almost any application and for a reasonably small amount of table rows per user, it is indeed very easy to implement: load all relevant data from the database - send it to the client - display it.
However, in most scenarios it is not possible to sufficiently restrict the amount of table rows and thus, with the previous approach the application would potentially load hundreds or thousands of records from the database, transfer it to the client and display it in one huge table. This is impractical ..
Getting started with Blaze-Persistence Entity Views
24 November 2016
Complex data models as can be encountered in nearly every bigger project will at some point require some kind of DTOs to avoid loading the full state of an entity. Depending on how good a mapping of an entity model to DTO model is implemented, the performance and maintainability will vary.
Normally, when implementing a DTO approach you do the following steps
Define the structure of what you want to consume e.g. the DTO definition
Think of a base query as source for the DTO instances
Transform the base query so that it produces the projections needed for the DTOs
Do the mapping from the
ResultSet-like structure to the DTO
Now you might skip 3. and instead of thinking of a base query like you should ..
Pagination powered by Blaze-Persistence
24 October 2016
Blaze-Persistence comes with great support for pagination. In this blog post I describe the different pagination modes that are supported and how to implement them with Blaze-Persistence.
Blaze-Persistence supports the following pagination modes:
Imagine your paginated data as an array of elements with a beginning and an end. For example, this array might be the content of a table in your database that you want to display pagewise. Offset pagination works by specifying an offset from the beginning of the array indicating the start of the current page. This can be problematic when elements are inserted into your array while users are paging through it.
For example, consider the following ..
Blaze-Persistence getting traction
18 October 2016
When I first started working on an early version of what now transformed into a fully fledged framework, I only wanted to be able to reuse queries which seemed to only differ in what they join fetch.
As of JPA 2.1 you could use "Entity-Graphs" to achieve that, but in the meantime I came up with a completely different approach that fixes all the problems you normally encounter when using join fetches and directly working with entities in general.
I won’t go into the details of the problems that arose when working with your entity model directly, but the general suggested solution to these problems is to use DTOs. JPA has some support for DTOs by supporting a so called "constructor expression", but it is limited in many ways so it’s practically only usable for simple cases.
The main goals of the first Blaze-Persistence versions ..