Introduction
In the last few weeks I saw a few blog posts and twitter statuses advertising that libraries just added support for Java 14 records or stated that they have been supporting it all along because there is nothing special to it. I have wanted to support custom entity view class implementations for a while and I finally managed to get around adding support for that. The best thing about it? You can now also use Java 14 records as entity views!
Java 14 introduces a new preview language feature called "records" which allows to eliminate language ceremony for immutable data holder types. Brian Goetz, the Java language architect, refers to records as being nominal tuples that are shallowly immutable.
What this means is that records ..
After a long Twitter discussion about the benefits of the separation of logic and projection concerns for database queries I thought it might be good to write a post about it. In software engineering, we usually agree that separation of concerns is a good thing as it allows to think about concerns in isolation which makes reasoning about behavior easier. Why not apply the separation of concerns principle to database queries as well?
When you fulfill a business use case that involves a database you usually have to think about the following things:
-
Formulation of the business use case as query to serve as data source
-
Definition of the structure of the result i.e. the DTO definition
-
Enrich the query for the business use case to fit the desired result structure
-
Map the query result to the desired result structure
As soon as you alter the business use case query ..
Introduction
The previous post took a little detour to showcase the filtering and sorting mechanism of Blaze-Persistence Entity Views, but this time we will take a look at mapping a DBMS array as collection in the entity model and also as collection in the entity view.
The use case for this example is that you want to be able to label/tag an object but want to avoid the join to a separate table because of performance reasons. Ideally, you would use an array type in the DBMS, but if the DBMS doesn’t offer such a type, you encode the array as string. Encoding it as string has a few problems though. You need to implement dedicated functions for operating on such values and have to choose a separator character that is not contained in values.
We have .. (click here to read more)
Introduction
This time we will take a little detour from presenting the different mapping types like in the last post and instead take a look at the filtering and sorting mechanism provided by Blaze-Persistence Entity Views.
When presenting data to an end-user you often try to present a denormalized view of the data that looks natural. Imagine you have a User type that has firstname, lastname and username attributes. Such a model is nicely normalized and for UIs that display just users, it’s probably a good idea to display the data in the normalized form.
When presenting the user as part of a different object i.e. as author of a post, we usually want to display the values in an aggregate/denormalized form. Imagine that you want to display posts in an overview table and also want to .. (click here to read more)
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 ..
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. ..
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 ..
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
..
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 ..
In this post I describe how to implement a paginated data table with filtering and sorting correctly and efficiently with the help of Blaze-Persistence and PrimeFaces.
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 ..
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 ..
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.
Pagination Types
Blaze-Persistence supports the following pagination modes:
-
Offset pagination
-
Keyset pagination
Offset pagination
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 ..
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 ..
Older posts are available in the archive.