Correlating unrelated entity types in Entity Views
17 July 2018
In the last post I have shown examples of subquery mappings and how they allow to correlate scalar values. This time I will show how to correlate multiple values as subviews with some common use cases.
Sometimes, correlating just a simple scalar value with a correlated subquery is just not enough and multiple values are required. Imagine you program the data access for a blog post and want to show the title and the text of a specific post but also the title and the first 100 characters of a previous blog post. How would you access the previous blog post based on the current blog post? You could of course simply do a separate query, or you take a look at ..
Blaze-Persistence now integrates with DeltaSpike Data
06 March 2018
The latest release of Blaze-Persistence provides an integration with DeltaSpike Data. This enables the use of entity views in CDI-based repositories in a similar fashion as with our already existing Spring Data JPA integration.
Do you enjoy creating your application’s data access layer using the elegance and brevity of repositories as provided by DeltaSpike Data or Spring Data? Then you will be delighted to hear that now you can do so efficiently, fetching only the data you need - and all this in a type-safe manner powered by Blaze-Persistence Entity Views. ..
Subqueries as Entity View attributes
25 October 2017
In the last post I have shown examples of collection mappings and how to combine the powers of collections and subviews. This time I will show how to map subqueries in entity views with some common use cases and discuss possible alternatives.
It is a quite common requirement to display the count of children or latest element of some object and this is where a correlated subquery comes in. Just as you would use a subquery as select item, you can make use of a subquery mapping ..
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
EntityManager. 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 throws a
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 ..