Hibernate UserType Example using Spring Data JPA

In Hibernate UserType Example using Spring Data JPA we will see how Hibernate allows us to implement and use custom types when built-in types do not satisfy an application’s requirements, or when we want to change the default behavior of a built-in type. As you will see, you can easily implement a custom-type class and then use it in the same way as a built-in one.

Hibernate provides an abstraction of database SQL types to prevent an application from getting mapped to underlying actual database column types. This allow us to develop an application without thinking about the target database column types that the target database supports and we easily develop our application and get involved with mapping Java types to Hibernate types. The database dialect which is a part of Hibernate responsible for mapping Java types to target database column types. If we write HQSL (hibernate query language) then we can easily switch to different database by changing the dialect without changing the application code.

For most of the mappings, Hibernate’s built-in types are enough but, in some situations, you may need to define a custom type. These situations generally happen when we want Hibernate to treat basic Java types or persistent classes differently than Hibernate normally treats them.

Continue reading “Hibernate UserType Example using Spring Data JPA”

Spring EnableEncryptableProperties with Jasypt

Spring EnableEncryptableProperties with Jasypt shows an example how to avoid putting clear text password for database connection credentials in properties file. Jasypt means Java simplified encryption. Here we are going to use Spring version 4 with Jasypt (Java simplified encryption). Here we are also going to use Spring Data JPA to perform the data layer activities with database.

If you put clear text password in properties file then everybody even people who should not see password would gain access to your database and may change database tables values, structure or even may delete without your consent. So it is always better to put the password in an encypted way to avoid such unwanted issues.

Here we will create Gradle based Spring Boot application with Spring Data JPA and apply Jasypt (Java simplified encryption) to extra layer of security for your password.

Jasypt Spring Boot provides Encryption support for property sources in Spring Boot Applications. There are 3 ways to integrate Jasypt in your spring boot project:

Simply adding the starter jar jasypt-spring-boot-starter to your classpath if using @SpringBootApplication or @EnableAutoConfiguration will enable encryptable properties across the entire Spring Environment

Adding jasypt-spring-boot-starter to your classpath and adding @EnableEncryptableProperties to your main Configuration class to enable encryptable properties across the entire Spring Environment

Adding jasypt-spring-boot-starter to your classpath and declaring individual encryptable property sources with @EncrytablePropertySource

Continue reading “Spring EnableEncryptableProperties with Jasypt”

Configure JNDI DataSource with Spring Boot


JNDI data source is very similar to JDBC data source. The JNDI data source accesses a database connection that is pre-defined and configured in the application server and published as a JNDI resource or service. Instead of specifying a driver and database as we do with JDBC data sources, we only need to specify the JNDI resource name in our application server.

Why do we use JNDI DataSource

JNDI comes in rescue when you have to move an application between environments: development -> integration -> test -> production. If you configure each application server to use the same JNDI name, you can have different databases in each environment but you need not to change your code. You just need to drop the deployable WAR file in the new environment.

You may also like to read Spring Data JPA CRUD Example and Spring Data JPA Entity Graphs

Continue reading “Configure JNDI DataSource with Spring Boot”

org.hibernate.MappingException: No Dialect mapping for JDBC type

You might have seen similar kind of exception occurred during performing native queries without entity class and this kind of issue may have been occurred in different databases such as MySQL, Oracle, SQL Server, PostgreSQL etc. Depending upon the database vendor you will get error for JDBC types -4, -9, 7 or 2003 etc. It means that Hibernate is unable to implement a type mapping for database type(for example, table column type float) to java type (float) though float type is listed in the JDBC reference.

Here I will create an example how to query Oracle database without entity class using Hibernate JPA and in what situation it throws the exception “org.hibernate.MappingException: No Dialect mapping for JDBC type: -9”. In this example I will also show you how to resolve the issue.

I assume that you are using Hibernate JPA with Spring Boot application.

Continue reading “org.hibernate.MappingException: No Dialect mapping for JDBC type”

Spring Data JPA Entity Graphs

One of the important features in JPA 2.1 is the ability to specify fetch plans using Entity Graphs. This is useful since it allows you to customize the data that is retrieved with a query or find operation. It is expected to display data from the same entity in different and several ways when working with mid to large size applications. In other cases, you just need to select a smallest set of information to optimize the performance of your application.

Typically you do not have many mechanisms to control what is loaded or what is not loaded in a JPA Entity. You could use EAGER/LAZY fetching, but these definitions are pretty much static. You are unable to change their behaviour at runtime when retrieving data, meaning that you are stuck with what was defined in the entity. Changing these amid development is a nightmare, since it can cause queries to behave unexpectedly. Another way to control loading is to write specific JPQL queries. Continue reading “Spring Data JPA Entity Graphs”