Forem: Sohail Shah

Create Persistence Unit Without The persistence.xml file

Sohail Shah — Tue, 12 Sep 2023 13:41:47 +0000

When working with JPA with Java applications, we usually create a persistence unit in the persistence.xml file as below.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
             version="2.0">
    <persistence-unit name="myPersistenceUnit" transaction-type="RESOURCE_LOCAL">
        <description>persistence unit description</description>
        <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
        <exclude-unlisted-classes>false</exclude-unlisted-classes>
        <properties>
            <!-- Database connection properties -->
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="sa"/>
            <property name="javax.persistence.jdbc.password" value=""/>

            <!-- Hibernate properties -->
            <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
            <property name="hibernate.show_sql" value="true"/>
            <property name="hibernate.format_sql" value="true"/>
            <property name="hibernate.hbm2ddl.auto" value="create"/>
        </properties>
    </persistence-unit>
</persistence>

The persistence unit can also be created programmatically without creating an XML file.

The persistence unit is created as a Java class which represents all the properties present in the XML file. This class must implement the interface PersistenceUnitInfo which defines the contact that needs to be fulfilled in order to create the persistence unit.

public class MyPersistenceUnit implements PersistenceUnitInfo {
    @Override
    public String getPersistenceUnitName() {
        return null;
    }

    @Override
    public String getPersistenceProviderClassName() {
        return null;
    }

    @Override
    public PersistenceUnitTransactionType getTransactionType() {
        return null;
    }

    @Override
    public DataSource getJtaDataSource() {
        return null;
    }

    @Override
    public DataSource getNonJtaDataSource() {
        return null;
    }

    @Override
    public List<String> getMappingFileNames() {
        return null;
    }

    @Override
    public List<URL> getJarFileUrls() {
        return null;
    }

    @Override
    public URL getPersistenceUnitRootUrl() {
        return null;
    }

    @Override
    public List<String> getManagedClassNames() {
        return null;
    }

    @Override
    public boolean excludeUnlistedClasses() {
        return false;
    }

    @Override
    public SharedCacheMode getSharedCacheMode() {
        return null;
    }

    @Override
    public ValidationMode getValidationMode() {
        return null;
    }

    @Override
    public Properties getProperties() {
        return null;
    }

    @Override
    public String getPersistenceXMLSchemaVersion() {
        return null;
    }

    @Override
    public ClassLoader getClassLoader() {
        return null;
    }

    @Override
    public void addTransformer(ClassTransformer classTransformer) {

    }

    @Override
    public ClassLoader getNewTempClassLoader() {
        return null;
    }
}

All the properties present in the XML file are provided by overriding the methods of the PersistenceUnitInfo interface.

Persistence Unit Name

Every persistence unit must have a name, that's because there can be more than one persistence unit in a project but it is rare to have more than one.

@Override
public String getPersistenceUnitName() {
    return "mypersistenceUnit";
}

Persistence Provider Class Name

It is the JPA implementation provider that needs to be defined in the persistence unit. In my case it is Hibernate.

@Override
public String getPersistenceProviderClassName() {
    return "org.hibernate.jpa.HibernatePersistenceProvider";
}

Transaction Type

The persistence unit must also provide the transaction type it is going to use. Depending on the type of application transaction type is decided

@Override
public PersistenceUnitTransactionType getTransactionType() {
    return PersistenceUnitTransactionType.RESOURCE_LOCAL;
}

DataSource

For JPA to establish a connection to the database, it needs a data source object containing database credentials. In the XML file, we didn't need to define any data source, it automatically created one using some internal implementation. But in the Java class, it needs to be defined manually. The best way to create a data source is using a Hikari Data source object.
Add the Hikari dependency in the pom.xml file

<dependency>
    <groupId>com.zaxxer</groupId>
    <artifactId>HikariCP</artifactId>
    <version>5.0.1</version>
</dependency>

Now create the Datasource object and return it

@Override
public DataSource getJtaDataSource() {
    HikariDataSource dataSource = new HikariDataSource();
    dataSource.setJdbcUrl("database-utl");
    dataSource.setUsername("username");
    dataSource.setPassword("password");
    return dataSource;
}

Managed Classes

When using the XML file, the entities' objects were automatically registered and managed by the JPA. In the Java file, you need to define all the entity classes that need to be managed by the JPA.

@Override
public List<String> getManagedClassNames() {
    return List.of("org.com.model.Student");
}

It may or may not work even if you didn't define the entities in the file.
These are the minimum required configuration you need to run the application with JPA.

When using the XML file, EntityManagerFactory is created by passing the persistence unit name in the constructor.

EntityManagerFactory entityManagerFactory 
            = Persistence.createEntityManagerFactory("myPersistenceUnit");

To create an EntityManagerFactory with the Java class implementation, we do this

EntityManagerFactory entityManagerFactory =
      new HibernatePersistenceProvider()
        .createContainerEntityManagerFactory(new MyPersistenceUnit(), new HashMap());

The hashmap is used to pass properties, I have passed an empty hashmap here since we don't have any properties to pass.
Using the entity manager factory, an entity manager can be created as it is done normally.

Although the persistence unit class doesn't provide any performance benefits of kind over the use of persistence.xml file, the choice of which to use is purely based on one's personal preference. Maybe in your next project, if you don't want to deal with any XML files try creating your own persistence unit class.

OAuth 2.0 Simplified: Know What You Need To Begin

Sohail Shah — Tue, 29 Aug 2023 13:42:10 +0000

If you are a professional developer or someone who is starting out, you might have come across OAuth 2.0. You might have tried to learn more about it but found it a bit tricky to understand. That's okay because OAuth 2.0 can be a bit like a puzzle with various pieces involving technical terms and processes that might seem overwhelming

In this post, I'll try to go through the core concepts of OAuth 2.0 that will provide you with a strong foundation. We'll focus on the essential building blocks that form the basis of this authorization protocol.

Before we get started it is important to remember that OAuth 2.0 is a specification and does not provide any concrete implementation. Keeping that in mind let's get started.

In the OAuth 2.0 specification, there are 4 main actors or roles.

Resource owner - It is the user who is trying to access a resource
Client - The client can be the browser, mobile app, desktop app, or any other application.
Resource Server - It is simply the backend of an application that hosts the protected resources(APIs). The user can access the resources on the backend through a client using a request protocol like HTTP using access tokens.
Authorization Server- The server that issues access token to the client after successful authentication. Using the access token, protected resources on the resource server can be accessed by the user through the client.

Authorization Grant

Authorization Grant is a credential that gives that client authorization to obtain access token from the Authorization Server. There are a few grant types but we'll discuss following the types because these are the recommended ones to use.

Authorization Code
Client Credential
Refresh Token

Authorization Code

After a user successfully authenticates itself with the authorization server, the authorization server sends the client an authorization code. The authorization code is kind of a key or a secret. The client can now make a POST request using this authorization code and get an access token back. It is important that the client itself should authenticate with the authorization server when making the request.

The above shows the typical flow for grant type of Authoziraztion Code.

Points to remember:

When the user is not logged in and tries to perform an action on a specific URL, the user is redirected to the login, and the same URL is passed to the Authorization.

For example, a user tries to comment on a post on Reddit on the URL reddit.com/r/java/post10. The user is redirected to the login page and the same URL is passed to the authorization server. After entering the user credentials and completing the flow to get the access token, the user is again redirected to the reddit.com/r/java/post10 URL.

The login page is not provided by the client (front-end application) but by the Authorization Server itself.

For example, when you log in to Reddit and select Google to log in. The login page to select Google account is provided by Google, not Reddit. The same goes for other OAuth 2.0 login providers like Github, Facebook, Apple, etc.

A user's login credentials are never shared with the client. The login credentials are directly processed by the Authorization Server.
After successful user authentication, the Authorization Server sends the client Authorization Code. The Authorization Code can be used only once by the client to get access token. It doesn't matter whether the request by the client was successful or not, once the Authorization Code is consumed by the Authorization Server it cannot be used anymore.
When the client makes the POST request to get access token, the client itself has to authenticate with Authentication Server by using some kind of authentication mechanism like Http Baisc.
The Authorization Server manages both the user credentials and the client credentials. The user credentials are usually username and password. The client credentials are clientId and secret.

Authorization Code With PKCE

PKCE stands for "proof Key for Code Exchange". It is an extension to OAuth 2.0 for native client applications which store the client credentials in the application itself. The client credentials can be compromised when it resides in the codebase of native applications like mobile apps. In web apps, the client credentials are safe enough as the code is present on the server that is not accessible to the public. But it is recommended to use PCKE even for web apps because your applications can never be safe enough.

Two things we need to know when dealing with PKCE is verifier and challenge. The verifier can be a random piece of string, or code and the challenger is a hash value of the verifier

verifier = "random string code"
challenge = hash(verifier)

Let's see the steps involved

When the user is redirected to the login page, the client application generates the verifier and the challenge.
The challenge is sent to the Authorization Server along with user credentials for authentication request.
After successful authentication and getting the Authorization Code, the client makes the request to get the access token, and instead of sending the client credentials along with the request the client sends the verifier to the Authorization Server.
The Authorization Server that already has the challenge now can validate if the verifier is indeed the same as the challenge by using the hash function matches.

//Authorization Server has the challenge already 
tempChallenge = hash(verifier)
if(tempChallenge.equals(challenge))
//If it is equal, client validation is successful and access token is genereated

Points to remember:

The verifier never leaves the client, so it is never exposed to the public.
The hash function and the algorithm used by the function is only known by the client and Authorization Server.

Client Credentials

In situations where there is no user, the client acts on its own behalf and can request access to resources on the Resource Server. For example, services in a microservice, monitoring tools, and orchestration tools like Kubernetes can request access to resources from a Resource Server. Since there is no user here, they act like a client and need client credentials to be validated by the Authorization Server to get a token. Only then using the tokens these clients can access the protected resources.

Refresh Token

We have already seen the flow for getting an access token after the user has been authenticated. The access token always expires after a prescribed amount of time then the user has to log in to get the access token again. Instead of the user logging in again, a refresh token is used to get the access token. This client is configured such that once the access token expires, it uses the access token to get a new access token and the refresh token. This happens without the user ever knowing.

These are the basic building blocks that you can use to create your own Oauth 2.0 authorization mechanism using any popular OAuth 2.0 provider like OpenID Connect(OIDC) or Keycloak. There are many other providers available and you can easily work with any of them if you have understood the basics fundamentals we have discussed in this post.

In the next post, we'll implement OAuth 2.0 with OIDC as an implementation provider using Spring Boot and check out some endpoints we need to know to validate and generate different tokens. So make sure to follow and leave a like on this post.

Using Optional in Java the right way

Sohail Shah — Mon, 21 Aug 2023 13:22:13 +0000

It doesn't matter how much time you have been programming, NullPointerException is one of the most frustrating problems you'll face.

The Optional class was introduced in Java 8 to tackle the problem of NullPointerException's.

The java.util.Optional class is a generic type class that contains only one value of type T. Its purpose is to provide a safer alternative to reference objects of a type T that can be null. But optional objects are safe only when used the right way.

Let's see the ways you can create optional objects

Empty Optional

Using the Optional.empty() we can create an optional object which is empty of any type


 Java
//returning a empty optional of type string
public static Optional<String> emptyOptional(){
       return Optional.empty();
    } 

//or
Optional<String> str = Optional.empty();

Nullable Optional

Using the Optional.ofNullable() method we can create nullable optional objects. These objects can be null or have values in them


 Java
public static Optional<Wallet> getWallet(){
        return Optional.ofNullable(null);
    }

Non-Nullable Optional

Using the Optional.of() method we can create non-nullable optional objects.


 Java
public static Optional<Wallet> getWallet(){
        return Optional.of(new Wallet(100));
    }

Now let's look at different methods present in the Optional class that we can leverage to write clean code promoting null safety.

The get() method in the optional class gets the value if it exists or throws a NoSuchElementException

For example, let's say we have an object Wallet with private filed money. To get the money value we can do as below


 Java
//normal way to get money 
int savings = wallet.getMoney();

//when wallet object is wrapped in a optional 
int savings = optionalWallet.get().getMoney();

If the wallet object is null the second way is safer than the first way as it thorws NoSuchElementException instead of NullPointerException

We can improve the second way by using the isPresent() method which returns a boolean for whether the value is present or not.


 Java
List<Integer> savings = new ArrayList();
if(optionalWallet.isPresent()){
    savings.add(optionalWallet.get().getMoney());
}

But at the same time, this way of doing is not less verbose than checking for not null.


 Java
List<Integer> savings = new ArrayList();
if(wallet != null){
  savings .add(wallet.getMoney());
}

To make the code more concise and clear, we can use ifPresent() method which takes a consumer or a runnable, or both. Using ifPresent() we can either consume a correct value or produce an alternative. Let's see how


 Java
List<Integer> savings = new ArrayList();
optionalWallet.ifPresent(wallet -> savings.add(wallet.getMoney()));

In the above example, money is added to savings only when the wallet is not null i.e., when it is present.

In case we were adding the wallet itself to the list


 Java
//using lambda
List<Wallet> wallets  = new ArrayList<>();
optionalWallet.ifPresent(wallet -> wallets.add(wallet));

//you can also use method reference
List<Wallet> wallets  = new ArrayList<>();
optionalWallet.ifPresent(wallets::add);

As you can see it is much better than the examples in the beginning.

There can be some scenarios where you might want to have a default value when the optional is empty, using the orElse() method we can produce an alternative value when the optional is null. Let's see an example


 Java
List<Wallet> wallets  = new ArrayList<>();
Wallet wallet = optionalWallet.orElse(new Wallet(0));
wallets.add(wallet);

In the above example, if the optionalWallet contains a value it is assigned to the wallet variable if not a default wallet with value 0 is assigned. The orElse() method can be used with any other type to produce default values.

You can also invoke a block of code inside the orElseGet() method to calculate a default value


 Java
//calculating a default value 
Wallet wallet = optionalWallet.orElseGet(() -> {
            int randomAmount = (int) (Math.random() * 500); // Generating a random amount between 0 and 500
            return new Wallet(randomAmount);
});

When working with spring boot applications and a database, when we make a select query to get a user, it is a good practice to wrap the user object around an optional, then we can do something like this


 Java
//Getting the user from database
Optional<User> findUserById(String id);

//Calling the find user method 
User user = findUserById(id)
                    .orElseThrow(UserNotFoundException::new);

In the above example, you can see, we didn't have to do any checks whether the user is not or not. If the user is present in the database we'll get the user, if not we gracefully throw an exception then and there itself.

These were some better ways to use the Optionals in Java. If you found this helpful post consider following and leave a clap.

Transactions And Transaction Propagation

Sohail Shah — Wed, 16 Aug 2023 05:14:06 +0000

Let’s begin this post, by understanding what is a transaction

What is a Transaction?

To define in simple terms, a transaction is an atomic unit of work. In the context of software applications, it represents a single, coherent unit of work that consists of multiple operations.

Transactions primarily belong to the context of databases. A transaction in a database represents a unit of work that consists of multiple database operations such as insert, select, update, or delete. While transactions are managed by the database itself, software applications that connect with the database play a vital role in initiating and controlling the transactions.

Transactions are a fundamental aspect of relational databases and even some non-relational databases also provide transactional ability.

Why the need for transactions?

The purpose of using transactions is to ensure data integrity and consistency. When multiple operations are grouped into a transaction, they are either all completed successfully or none of them are applied, which helps maintain the accuracy and reliability of the data.

E-Commerce, banking and finance, reservation systems, and supply chain management are a few examples of domains where their software applications need to have consistent and accurate data to perform operations without discrepancies and guarantee reliable customer experience.

Let’s take an example of buying a product from an e-commerce site. When the buy product button is clicked, the order is confirmed. To confirm the order multiple operations can take place like checking product availability, reserving the product, updating the inventory, creating the order, payment, and order confirmation.

This is just an example, in a real case much more complicated operations take place.

The buy-product method is put in a transaction context to make sure all the operations occur or neither of them.

The annotation is used in spring applications to define and manage transactions for methods.

When a method is marked with @Transactional annotation by default:

Changes are rollbacked if any RuntimeException is thrown by the method
Changes are not rollbacked if any Checked Exception is thrown by the method

This default behavior for rollback can be changed by passing particular RuntimeExceptions and Checked Exceptions for rollbackFor and noRollbackFor parameters for the @Transactional annotation



 Java

@Transactional(

            rollbackFor = DuplicateUserException.class,

            noRollbackFor = IllegalArgumentException.class

)

Transaction Propagation

In spring applications, to execute a method in a transaction context, the @Transactional annotation on top of a method. When a method with a transaction calls multiple other methods, transactions are propagated from one method to another. We might want to manage the transaction propagation behavior differently to different methods depending on their functionality.

From the above example, we know that single action, such as buying a product, involves carrying out several individual tasks. The buy method will include all the individual method calls to make up a single cohesive unit.

Propagation.REQUIRED

By default, propagation is set to required. When a method is annotated with @Transactional(propagation = Propagation.REQUIRED), the method will always require a transaction context to execute.

Method marked with Propagation.REQUIRED when called from another method.

If there is no transaction, a new transaction is created
If a transaction is already present, the method is executed in the same transaction context

In our example, let’s say the check product availability is marked with required propagation, so it will execute in the same transaction context as buy product method.

Propagation.REQUIRES_NEW

When a method is marked with @Transactional(propagation = Propagation.REQUIRES_NEW), a new transaction context is created every time the method is executed, even if it is called from a method with a transaction already present.

There can be a requirement such that if one particular operation like sending mail is part of the buy-product method, fails for some reason you don’t want the entire transaction to fail. Because sending mail should not affect the customer buying the product.

Propagation.MANDATORY

As the name suggests, when a method is marked with @Transactional(propagation = Propagation.MANDATORY), it always requires a transaction context to execute.

Using this propagation doesn’t create a transaction of its own but makes sure that there is a transaction context when calling the method.
Methods marked with mandatory, when called from a method that doesn't have any transaction will fail with an exception from the transaction manager

Propagation.NEVER

When a method marked is marked with @Transactional(propagation = Propagation.NEVER), it means never it requires a transaction context for execution.

If a method is marked with Propagation.NEVER and called from a method with a transactions context, it will with an exception. It behaves the opposite of Propagation.MANDATORY

Propagation.SUPPORTS

When a method is marked with @Transactional(propagation = Propagation.NEVER), the method can be called from a transaction context or without a transaction context.

As the name implies, it supports being executed in a transaction context but doesn’t create a new transaction on its own rather executes within the called methods transaction context. At the same time, the method can also be called from a method with no transaction context just like a normal method. Propagation.SUPPORTS is like a middle ground for Propagation.MANDATORY and Propagation.NEVER

Propagation.NOT_SUPPORTED

When a method is marked with @Transactional(propagation = Propagation.NOT_SUPPORTED), the method executes without a transaction.

The method can be called from a method either with a transactional or without a transaction. But even when called from a method with a transaction context, the method marked with Propagation.NOT_SUPPORTED will always execute with any transaction context.

Let’s say the buy product consists of a method that has a single select query that reads data from the database. It’s logical that this method doesn’t require any transaction for execution as it is not making any changes to the database.

If you liked this post leave a reaction, we'll cover transaction isolation in another post

Implement Service Discovery Pattern With Eureka And Consul

Sohail Shah — Mon, 31 Jul 2023 12:17:38 +0000

In the previous post, we looked at what Discovery Server in microservices is and what are the problems it solves. In the post, we’ll implement the service discovery pattern with Eureka and Consul with Spring Boot.

Netflix Eureka

Netflix Eureka is one of the most popular open-source solutions to achieve service discovery. Eureka is also part of Spring Cloud tools, providing quick and easy configuration to get started.

Let’s set up the discovery server. Create a spring boot application with only the following dependency. You can use the spring initializer site to create the application easily. If you don’t use the spring initializer site, make sure to add the cloud dependencies.


 XML
<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

The next step is to add the @EnableEurekaServer annotation on top of the main class of the application. Adding this annotation is optional. It does not affect the discovery server functionality. It is just for code readability.

With the dependency added and spring boot providing auto-configuration with sensible defaults, we can run the application and it’ll work fine. But you’ll see some error messages in the console that’s because by default the discovery server also acts as a discovery client and tries to register itself with other discovery servers. In this demo, we only have one discovery server. We have to configure our discovery server such that it does not act as the client itself.

Configuring the discovery server can be done in two ways, either programmatically by defining beans or by defining the configuration in the application.properties or the application.yml file. It is recommended to do it in the yml file.


 YML
spring:
  application:
    name: discovery-client

server:
  port: 8761

eureka:
  client:
    register-with-eureka: false
    fetch-registry: false

In the yml file, the discovery server port is set to 8761 as is the default port. The Eureka client properties register-with-eureka and fetch-registry is set to false.

Setting the register-with-eureka property to false stops the discovery server to register itself with other discovery servers and setting the fetch-registry to false stops our discovery server to fetch registry data from other discovery servers since there is only one discovery server in this demo.

Now let’s set up the discovery client(s), that can be discovered by the discovery server. The discovery client is our spring boot application providing services as a microservice. You can create a new spring boot application or use an existing application to act as a discovery client that can register itself with the discovery server.

All you have to do is to add the following dependency and we are ready to run the application.


 XML
<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

In the application.yml file, change the name of the application to see the same name in the service registry.


 YML
spring:
  application:
    name: discovery-client

server:
  port: 9000

Now with both applications running, visit localhost:8761 in the browser. We can see that our client application has successfully registered itself with the discovery server.

We have configured both the discovery server and the discovery client with the minimum configuration to set up the discovery service mechanism. That being said, the Netflix Eureka comes with many other features like loading balancing and there are tons of configurations available to make services secure, highly available, and resilient.

Check out the GitHub repository for the same.

HashiCorp Consul

Consul is a tool developed by HashCorp, known for developing Terraform. Apart from service discovery, the consul provides a key-value store, centralised configuration, network security, and several other features. But in this post, we are only interested in the service discovery aspect of it.

To get started with Consul, we can spin up a docker container or download the executable from the official site.

Let’s see how to run a docker container. First, pull the consul image using the command below.


 bash
$ docker pull hashicorp/consul

Create and run the container on the default port 8500 with below command


 bash
$ docker run --name consul -d -p 8500:8500 hashicorp/consul

The same can be done without docker by directly running the executable file downloaded.

Extract the .exe file and in the directory where the file is present run the following command in the terminal


 bash
.\consul agent -dev -enable-script-checks -node=web -ui

Note I’m running the command on windows. For other OS check out the official documentation

Now visit localhost:8500/ui to check out the web UI. In the services section, you can see one instance of consul discovery server running.

For the microservices to register themselves to the registry, add the following dependencies in the pom.xml file


 XML
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>

By adding the consul discovery dependency to the classpath of our application, spring-boot auto-configures the application to register itself with the consul service registry.

Also, we need the web dependency as the service discovery mechanism is happening over the **HTTP **protocol.

You can add the optional @EnableDiscoveryClient annotation on the main class of the application. In the application.yml file configure the name and port of the application.


 YML
spring:
  application:
    name: discovery-client

server:
  port: 900

Now if we run the application and check out the consul web UI. We can see that our application has registered itself in the service registery.

Check out the GitHub repository for the same.

If you liked this post, consider leaving a reaction and follow for more.

Service Discovery in Microservices

Sohail Shah — Wed, 26 Jul 2023 14:23:09 +0000

What is Service Discovery?

In modern cloud-based applications, there are multiple services running with multiple instances of some of them. It's common that each service communicates with each other to provide services. In order to communicate with each other each service need to know the network address and port other services.

We can hard code the network address and ports initially but we’ll run into a lot of problems quickly.

What if we need to dynamically scale horizontally meaning adding more instances of a service to handle increased load? How do we load-balance the requests to each instance?

In modern cloud applications, each service has its network address assigned dynamically, and the number of services running also changes frequently due to horizontal scaling.

Deploying new versions of services will break the communication if paths are hardcoded, communicating with new services becomes difficult and requires a lot of manual changes. Hence the need for a service discovery mechanism.

A service discovery acts as a registry that holds the addresses of all the instances of services

There are two types of Service discovery patterns
1.Client Side Discovery
2.Server Side Discovery

Client Side Discovery

In a client-side discovery mechanism, a service is responsible for determining the address of each instance available. Also, the service itself is responsible for load-balancing the requests between the instances using a suitable load-balancing algorithm.

Advantages of client-side service registry:

Straight forward to implement
Since addresses of instances are known beforehand, efficient load-balancing algorithms can be employed
In the event that the service discovery is down, the address can be cached to continue functioning.
Reduced latency as we don't have to make an extra hop if we had a centralized load balancer.

Disadvantages of client-side service registry:

The service is tightly coupled to the service registry
Each service must implement client-side discovery logic for the programming language and framework used by the service.

Server Side Discovery

In the server-side discovery mechanism, each service communicates with other services through a dedicated load balancer. The load balancer makes the request by querying the service registry and routes each request to the appropriate instance available.

Advantages of server-side discovery:

Service becomes lighter as it doesn’t have to deal with service registry lookups
No need to implement service discovery logic for different languages and frameworks used by services

Disadvantages of server-side discovery:

Set up and manage a dedicated load balancer
A centralized service registry can be a single point of failure for the entire system
Network latency is increased as each request has to go through the load balancer and service registry

Service Registration Model

Up until now, we have assumed that the service registry already knows the addresses of the services. Let's see how services register and deregister themselves with the service registry.

Self-Registration

In a self-registration model, each service has the responsibility of registering and de-registering themselves in the service registry. Once registered, the service needs to send hearts beats/ ping the service registry to keep the registration alive.

Third-Party Registration

In the third-party registration model, the services are not responsible for registering themselves to the service registry. Instead, another component in the system known as the service registrar is responsible for registering the services in the service registry. The service registrar keeps track of changes by polling the deployment environment or subscribing to events. When a new service is available it registers it in the service registry and de-registers it once it gets terminated.

In conclusion, service discovery is a database that has the addresses of the service instances. It must be highly available and up-to-date.

JPA : One-To-Many, Many-To-One And Many-To-Many Relationships

Sohail Shah — Fri, 21 Jul 2023 10:24:06 +0000

In the previous post, we looked at one-to-one relationship. In this post, we will look at one-to-many, many-to-one, and many-to-many relationships.

Many-To-One Relationship

In a many-to-one relationship, multiple entities are associated with exactly one other entity. In terms of database tables, multiple records in a table can be associated with exactly one record in other table.

To understand it better, let's create an entity called assignment. The assignment entity contains the following member variables.


 Java
@Entity
@Table(name = "grade_table")
public class Assignment {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private int id;
    private String title;
    @Temporal(value = TemporalType.DATE)
    private Date dueDate;
}

The idea here is that there can be many assignments assigned to a single student. Therefore, we can establish a many to one relationship between student and assignment entities.

To achieve this, we are going to use the @ManyToOne annotation. Now the question is in which entity do we put this annotation? In the student entity or in the assignment entity?

While modeling these kinds of relationships we also need to understand how table records are going to be affected, only then we can decide in which entity to put the annotation.

Let's assume we simply put in the student entity as we did in one to one relationship. Then it is expected that there is a foreign key column in the student table with the primary keys of assignment entities. since a student can have more than one assignment storing multiple keys in a single column is not possible.

It should be noticed that multiple assignments are going to be assigned to a single student. So instead we can store student ids in the foreign key column of the assignment table. Let's do that now


 Java
@Entity
@Table(name = "grade_table")
public class Assignment {
    .
    .
    .
    @ManyToOne
    private Student assignedTo;
}

Create a couple of new assignment objects and persist them in the database with the new relationship.


 Java
Assignment assl = new Assignment();
assl.setTitle("JAVA");
assl.setDueDate(new Date());
assl.setAssignedTo(studentl) ;
Assignment ass2 = new Assignment();
ass2.setTitte("DSA");
ass2.setDueDate(new Date()) ;
ass2.setAssignedTo(studentl) ;

In the database, we can see there is no change to the student table. The new assignment table has two assignments with the same student ids.

One-To-Many Relationship

If fetch student details we won't be able to get the assignments assigned to the students. That's because the student entity has no access to the assignment entity. As we have seen in the one-to-one relationship we can solve this by simply mirroring the relationship in the student entity. When mirroring the relationship it is important to define a primary entity and the other entity automatically becomes the mirrored entity. Which entity becomes the primary is up to the database design and the data itself. We discussed it in the previous post. Check it out to understand it in more detail and other implications of it.

To mirror the many-to-one relationship in the student entity, we need a list of assignments because there can be many assignments for a student.


 Java
@Entity
@Table(name = "Student_Table")
public class Student {
    .
    .
    .
    @OneToMany(mappedBy = "assignedTo")
    private List<Assignment> assignmentList;
}

One-to-many and many-to-one mirror each other. Sometimes we can get confused about which annotation to use in which entity. well here’s a trick, In the above example Student entity has many assignment entities. Read it as one student has many assignments. Thus @OneToMany annotation. In the same way, the assignment entity read it as many assignments but one student thus @ManyToOne annotation.

Let's fetch the student details again and see the result.

Since student and assignment entities mirror each other's relationship, make sure to format the toSting() method in both entities properly so that they don't access each other's data resulting in an infinite loop.

The two assignments are present in the student details. Now we can easily access the assignment data from the student data and vice versa.

Fetch Type

In the previous post, we saw that the default fetch type is eager. But that's not the case with many-to-one and one-to-many relationships. The default fetch type is lazy. It makes sense because we don't want to fetch different multiple entities along with the student entity. The assignment data is fetched only when it is accessed.

Do check the hibernate-generated queries to understand more in detail.

Many-To-Many Relationship

To understand the many-to-many relationship let's create an entity called club. The club entity contains the following member variables


 Java
@Entity
@Table(name = "Student_club")
public class Club {
    @Id
    @GeneratedValue
    private int id;
    private int name;
}

In a many-to-many relationship, multiple records in one table can be associated with multiple records in another table. In our example, a student can be part of many clubs, and a club can have many students. To represent this relationship in a database, we typically use a junction table or an associative table.

In the case of one-to-many and many-to-one relationships, we noticed that a foreign key in a table can reference only one primary key. So we referenced the primary keys of the student to the foreign key column of the assignment table. But in the case of many-to-many relationship, it is not possible to directly use a single foreign key to establish the association between the two entities. This is because both entities are associated with multiple instances of each other.

This problem is solved using a junction table approach. A junction table is an entirely new table that acts as a bridge between the two entities and establishes the many-to-many relationship. In a junction table, there exits foreign key columns that contain the primary keys of both entities.

Now let's add the @ManyToMany annotation to the member variables of the entities we want.


 Java
@Entity
@Table(name = "Student_club")
public class Club {
    @Id
    @GeneratedValue
    private int id;
    private int name;
    @ManyToMany
    private List<Student> studentList;
}


 Java
@Entity
@Table(name = "Student_Table")
public class Student {
        .
        .
    @ManyToMany  
    private List<Club> clubs;
}

If you noticed, the members are of type list indicating the kind of relationship we are establishing here. We might have members annotated the variables are annotated with @ManyToMany but it doesn’t precisely establish the relation as we want.

Let's create a couple of club and student objects and persist them in the database. By doing so we can observe what exactly happens to the database tables.


 Java
//Student 1 object
Student student1 = new Student();
student1.setName("Sohail Shah");
student1.setAge(18);
student1.setAdmission_no("1234");
student1.setDob(new Date());
student1.setStudentType(StudentType.SCHOLARSHIP);
//Student 2 object
Student student2 = new Student();
student2.setName("Ali");
student2.setAge(20);
student2.setAdmission_no("1235");
student2.setDob(new Date());
student2.setStudentType(StudentType.NON_SCHOLARSHIP);
//club 1 object
Club club1 = new Club();
club1.setName("Java Club");
club1.addStudent(student1);
club1.addStudent(student2);
student1.addClub(club1);
student2.addClub(club1);
//club 2 object
Club club2 = new Club();
club2.setName("Spring Club");
club2.addStudent(student2);
student2.addClub(club2);
student1.addClub(club1);
student1.addClub(club2);
student2.addClub(club1);
student2.addClub(club2);
//persisting the objects                
entityManager.persist(student1);
entityManager.persist(student2);
entityManager.persist(club1);
entityManager.persist(club2);

After running the application, in the database, we'll have two different tables with the same data or foreign keys that are just mirrored.

The JPA doesn't know both these tables contain the same data and it is tracking them twice.

This is easily solved by using the mappedBy parameter in the many-to-many annotation. We have used this in other relationships too. You can put the mappedBy in any of the entities.


 Java
@ManyToMany(mappedBy = "clubs")
private List<Student> studentList = new ArrayList<>()

If we run the application again, there should be only one table containing the primary keys of both entities.

Make sure you properly use <property name="hibernate.hbm2ddl.auto" value="create"/> in order to see the correct data. If getting errors just drop tables and run the application again.

Fetch

The default fetch type for many-to-many relationship is lazy same as one-to-many and many-to-one. You can of course change this default behaviour by using the FETCH.EAGER and FETCH.LAZY

Deciding the fetch type depends on your database schema and needs. A lazy fetch type is usually recommended for many-to-many relationships.

Different Ways To Use Comparator Interface in Java

Sohail Shah — Sat, 15 Jul 2023 13:45:32 +0000

In this post, we will explore various ways to use the Comparator interface in Java to compare objects and sort collections

Let's assume we have a list of Student objects, with a Student class that has some member variables. We'll use this as an example through the post.

public class Student {
    private int id;
    private String firstName;
    private String lastName;
    private Date age;
}

List<Student> list = new ArrayList<>();

1. Create a Class Implementing Comparator

One way to use the Comparator interface is by creating a separate class that implements the Comparator interface. This class will provide the logic for comparing objects based on specific criteria. You can then instantiate this class and use it to sort collections of objects. This approach allows for a flexible and reusable way of defining custom sorting logic.

Now let's create our custom class that implements the Comparator Interface

class StudentComparator implements Comparator<Student>{
    @Override
    public int compare(Student o1, Student o2) {
        return o1.getId() - o2.getId();
    }
}

This class compares the students based on their id's. Now passing an instance of this class in the sort method of the Collections util class sorts the list in ascending order of id's

StudentComparator studentComparator = new StudentComparator();
Collections.sort(list,studentComparator);

This is one way to use the Comparator interface. You can create multiple classes implementing the comparator interface for different custom sorting logic.

2. Using Lambda Expressions

Another way to utilize the Comparator interface is by using lambda expressions. Lambda expressions provide a concise way to define the comparison logic inline, without the need to create a separate class. This approach is often preferred for simple comparisons and can lead to more readable code.

Comparator<Student> compareWithId = (s1, s2) -> s1.getId() - s2.getId();
list.sort(compareWithId);

3. Using Method Reference

Method reference is another approach to using the Comparator interface. It allows you to refer to an existing method and use it as the comparison logic. This approach can be useful when you have an existing method that already provides the desired comparison behavior. Method references reduce code duplication and enhance code readability.

list.sort(Comparator.comparing(Student::getFirstName));

This is so much simple than the previous ones.

4. Creating a Utility Class

If you find yourself using the same comparison logic across multiple projects or classes, it may be beneficial to create a utility class. This utility class can contain static methods that implement the comparison logic you need. By encapsulating the comparison logic in a utility class, you can easily reuse it and keep your code clean and organized.

public class StudentUtil {
    public static Comparator<Student> compareById(){
        return Comparator.comparing(Student::getId);
    }
    public static Comparator<Student> compareByFirstName(){
        return Comparator.comparing(Student::getFirstName);
    }
    public static Comparator<Student> compareByLastName(){
        return Comparator.comparing(Student::getLastName);
    }
    public static Comparator<Student> compareByAge(){
        return Comparator.comparing(Student::getAge);
    }
}

Now you can use the static methods of the utility class in multiple classes in your project.

list.sort(StudentUtil.compareByAge());

By exploring these different ways of using the Comparator interface, you can gain a deeper understanding of how to compare objects and sort collections based on different criteria. Each approach has its own benefits and can be selected based on the complexity of the comparison logic and the specific requirements of your project.

I hope this blog post helps you in understanding the different ways to use the Comparator interface. Happy coding!

Follow me on : Twitter, LinkedIn, GitHub, Linktree

JPA: One-To-One Relationship, Fetch type, Relationship Direction, And Query Optimization

Sohail Shah — Tue, 11 Jul 2023 15:26:11 +0000

In the previous posts, we had only a single entity called the student. Let's create another entity named the library card. The library card entity will have its own table in the database with its own primary id column.

@Entity
@Table(name = "library_card")
public class LibraryCard {
    @Id
    @GeneratedValue
    private int id;
    @Temporal(TemporalType.DATE)
    private Date issuedDate;
    private boolean isActive;
}

Just like the student entity we have annotated the library card with @Entity annotation and its member variables with proper annotations.

We can create and persist library card entities in the database just like we persisted the student entities. What we want to do here is for each student to have exactly one library card.

To do it a simple way we might add a library card member variable in the student entity and store the primary key values of the corresponding library card in It. Using these primary key values of library cards we can reference the library cards table itself.

@Entity
@Table(name = "student_table")
public class Student{
    .
    .
    private int library_card;
    .
    .
}

That might look simple and easy, but doing things that way will only create tons of problems in the future causing database inconsistencies.

Apart from that, we really didn't create any relationship between the two tables in the database or in the Java side of things. The library card column in the student table only contains a value that is supposed to be a primary key for the library card table but doesn't guarantee it.

The solution for this problem is relationships provided by JPA. The different relationships we can define are one-to-one, one-to-many, many-to-one and many-to-many.

Using a proper relationship for tables requires us to understand our data itself. In our example, each student can have only one library card. So the proper relationship to use here is a one-to-one, relationship.

One to One relationship

In a one-to-one relationship, one entity is associated with exactly one other entity. In terms of database tables, each record in a table is associated with exactly one record in another table. In our example, one student can have only one library card and vice versa.

In our student entity, instead of a member variable library card which is of primitive type int let's replace it with a variable card of type LibraryCard which is a entity itself.

@Entity
@Table(name = "student_table")
public class Student{
    .
    .
    private LibraryCard card;
    .
    .
}

If we run our application we’ll get an error, that’s because hibernate doesn’t know how to persist the non-primitive type card member.

The annotation we are looking for is @OneToOne. By sticking this annotation on top of our card variable we telling JPA about the relationship we want to have between the library card entity and the the student entity.

@OneToOne
private LibraryCard card;

Now let's create a couple of library cards and persist them in the database just like we persisted student entities.

public class Main {
    public static void main(String[] args) {
        EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("myPersistenceUnit");
        EntityManager entityManager = entityManagerFactory.createEntityManager();

        Student student1 = new Student();
        student1.setName("Sohail Shah");
        student1.setAge(18);
        student1.setAdmission_no("1234");
        student1.setDob(new Date());
        student1.setStudentType(StudentType.SCHOLARSHIP);

        Student student2 = new Student();
        student2.setName("Ali");
        student2.setAge(20);
        student2.setAdmission_no("1235");
        student2.setDob(new Date());
        student2.setStudentType(StudentType.NON_SCHOLARSHIP);

        LibraryCard card1 = new LibraryCard();
        card1.setActive(true);
        card1.setIssuedDate(new Date());

        LibraryCard card2 = new LibraryCard();
        card2.setActive(false);
        card2.setIssuedDate(new Date());

        EntityTransaction transaction = entityManager.getTransaction();
        transaction.begin();
        entityManager.persist(student1);
        entityManager.persist(student2);
        entityManager.persist(card1);
        entityManager.persist(card2);
        transaction.commit();
        entityManager.close();
        entityManagerFactory.close();
    }
}

This is how the database currently looks. card_id column is set to null because we have set the relationship between the tables but haven't set the values for it. Let's do that now.

Add these lines before persisting the entities.

student1.setCard(card1);
student2.setCard(card2);

If we look at our database now we can see that the primary keys of the library cards are present in the card id column of the student table

This might look the same as we tried to do without the @OneToOne annotation just by simply storing the primary key. But here we have actually defined an actual relationship between the two tables.

The card_id column contains the key called the foreign key. The Foreign key is important in databases because it helps create relationships between tables. This foreign key column contains the primary key of a different table. There are different types of keys available like the composite key, alternate key, super key, and several other keys. These keys are used for different purposes in a database.

Now that we have a relationship between our entities, it becomes easier to work with them. This relationship brings referential integrity to our database. It ensures correct values are inserted and manages the data consistency for us.

Fetching

Let's fetch a student from the database and see what it looks like now that it has a relationship with the library card table.

EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("myPersistenceUnit");
EntityManager entityManager = entityManagerFactory.createEntityManager();
Student student1 = entityManager.find(Student.class, 1);
System.out.println(student1)

Add proper toString() method to entities for them to print correctly

This is the result of the fetch. Notice that we only fetched the student details but along with it it also fetched the library card details. Since the one-to-one relationship is defined between the two entities, fetching hibernate generates a join query also to fetch the library card details.

This behaviour can be suitable in some situations and not in others. For example, let's say our student entity has multiple other relationships with different entities. So when we fetch student details, all the other entities which are in a relationship are also fetched. But we might not want the data of all entities in relationship with the student entity.

JPA provides a way to change this behaviour of fetching. We can change this behaviour by configuring the one-to-one annotation. There are two fetch types. The Eager fetch and the lazy fetch.

Eager Fetch

By default, one-to-one annotation is set to eager fetch type. When the fetch type is set to eager the relationship data is fetched along with owner entity data, as we have seen above.

@OneToOne(fetch = FetchType.EAGER)
private LibraryCard card;

Lazy Fetch

@OneToOne(fetch = FetchType.LAZY)
private LibraryCard card;

When the fetch type is set to lazy, the relationship data is not fetched instantaneously. It is only fetched when it is needed.

If we run the application with fetch type lazy, In the generated query you can see there is no join clause. The library card data is fetched as a separate query when required.

Relationship Direction

The direction of a relationship can be unidirectional or bidirectional.

In a unidirectional relationship, one entity acts as the owner of another entity. In our case, logically speaking, a student must possess a library card and not the other way around. Therefore, the student entity owns the library card entity. The student entity can access the library card entity's data. However, the library card entity cannot access the student entity's data without explicitly writing queries for it.

In a bidirectional relationship, both entities have access to each other's data without writing queries explicitly.

To make a bidirectional relationship between student and library card entities, we have to add the Student as a member variable in the library card entity with one-to-one mapping.

@Entity
@Table(name = "library_card")
public class LibraryCard {
    @Id
    @GeneratedValue
    private int id;
    @Temporal(TemporalType.DATE)
    private Date issuedDate;
    private boolean isActive;

    @OneToOne
    private Student owner;
}

Before persisting the student and library card entities, add the following lines and run the application. Our database should look like this. Both the student table and card table store information about each other.

card1.setOwner(student1);
card2.setOwner(student2);

With this, we have access to student entity data with library card.

LibraryCard libraryCard = entityManager.find(LibraryCard.class, 3);
System.out.println(libraryCard.getOwner());

We are able to get the student details. But let's look at the generated query.

Library card details are being accessed multiple times as the library card is present in the student entity as well, even though we already have the card details. Hibernate doesn't recognize that the same library card is being queried again, even though they are in a bidirectional relationship. This is inefficient and can lead to issues.

What we want is to inform Hibernate that the student entity is the primary entity and the library card entity is its mirror. So when we query for a student, we also want to retrieve the library card details. However, when we query the student details from the library card entity, which also contains the same library card, we don't want to perform an additional query. This can be achieved by using the "mappedBy" parameter in the OneToOne annotation.

@OneToOne(mappedBy = "card")
private Student owner;

Now when we run the application again, the library card is queried only once.

In this post, we have not only covered the one-to-one relationship, but also the fetch types that determine when to fetch data, the direction of relationships, and optimizing queries.

If you liked this post, please leave a reaction.

Follow me on : Twitter, LinkedIn, GitHub, Linktree

Dive into the Spring Security Architecture

Sohail Shah — Sun, 02 Jul 2023 13:06:16 +0000

In this post, we'll be looking at the components that form spring security and understand how the spring security architecture works. By getting to know the components of spring security and their working, it becomes easy to configure and implement our own security mechanisms.

Components of Spring Security

The following are the basic components that form the spring security architecture.

Filters
Authentication Manager
Authentication Provider
User Details Service
Password Encoder

Let's talk about each one of them in detail

Filters

In spring applications, every request needs to pass through a chain of filters before the request ends up in the controller class. These filters are responsible for the authentication and authorization of users and their requests to access resources.
The filters check the validity of each request based on internal rules defined. You can create your custom filters with your own rules.

Let's say the request is in the authentication filter. The authentication filter is responsible for extracting user authentication details and tokens. These user details are packaged as authentication objects and passed to Authentication Manager.
The auth object is created using an implementation Authentication interface such as UsernamePasswordAuthenticationToken.

Authentication Manager

public interface AuthenticationManager {
    Authentication authenticate(Authentication authentication) throws AuthenticationException;
}

The Authentication Manager receives an authentication object from the authentication filter. Authentication Manager is an object whose responsibility is to find a way to authenticate users. That is achieved by using Authentication Provider.

In a typical spring security configuration, there is only one Authentication Manager which delegates the authentication request to the correct Authentication Provider.

The Authentication Manager interface has only one method called authenticate that takes in an authentication object passed down from the authentication filter. Upon successful authentication of the user, the Authentication Manager returns an authenticated Authentication object.

Authentication Provider

public interface AuthenticationProvider {
    Authentication authenticate(Authentication authentication) throws AuthenticationException;

    boolean supports(Class<?> authentication);
}

There can be multiple Authentication Providers in a spring security context. Every Authentication Provider is responsible for handling different authentication mechanisms. For example, a spring application can have both username and password authentication as well as HttpBasic authentication. For both of these authentication mechanisms, there will be an Authentication Provider implementation.

The Authentication Provider interface has a authenticate method like the Authentication Manager and a supports method.
The supports method checks if the current provider supports the authentication for the given type of credentials, if not the credentials are passed to the next provider/filter.

The authenticate method actually validates the credentials or tokens of the user. This method gets the user details using the UserDetailsService interface which is responsible for retrieving user details from a user store-like database. Upon successful authentication, the method returns an authenticated Authentication object back to the Authentication Manager. At last, this authenticated object is stored by the Authentication Manager in the spring security context, which holds the users' authentication information. This information can be accessed throughout the application.

UserDetailsService

The UserDetailsService interface has only one method loadUserByUsername which takes the username from the authentication object passed down from the filter.

The loadUserByUsername method returns a UserDetials object which contains user details like username, password, authorities and, other details.

public interface UserDetailsService {
    UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;
}

public interface UserDetails extends Serializable {
    Collection<? extends GrantedAuthority> getAuthorities();

    String getPassword();

    String getUsername();

    boolean isAccountNonExpired();

    boolean isAccountNonLocked();

    boolean isCredentialsNonExpired();

    boolean isEnabled();
}

Password Encoder

Since we are talking about security, it is very important that the users' passwords are secured for the entirety of the authentication process. Spring Security comes with some de facto password encoders out of the box. This makes it easier for us developers to manage users while authenticating and storing them in the database.

Some popular implementations of the PasswordEncoder interface are BCryptPasswordEncoder, SCryptPasswordEncoder, and AbstractPasswordEncoder.

To work with the password encoder, define a bean that returns a type PasswordEncoder

@Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

Now you can inject this bean in the user service to encode the password before storing it in the database and in the authentication provider to decrypt the password for validation.

Knowing and understanding these components of spring security helps to implement security better for our applications.

If made any mistakes please point it out in the comments.

Follow me on : Twitter, LinkedIn, GitHub, Linktree

Persisting non-primitive types in JPA

Sohail Shah — Sun, 25 Jun 2023 17:16:59 +0000

In this post, we'll look at how we can persist non-primitive data types in JPA.

The primitive data types like int, char, byte, String, boolean, or their respective wrapper classes are mapped automatically by default into the correct database types by implementing ORM frameworks like Hibernate or EclipseLink.
The same is not true for non-primitive data types like Date and Enumeration.

Let's see how possible solutions to persist them.

Date

Let's consider an example where we have a Student entity class with a member variable dob(date of birth).

@Entity
@Table(name = "Student_Table")
public class Student {
    @Id
    @GeneratedValue
    private int id;
    private String admission_no;
    @Column(name = "student_name")
    private String name;
    private int age;
    private Date dob;
}

The Date here is from the java.util.Date package not java.sql.Date which is a subclass of java.util.Date package. Even though the sql Date is the type that is persisted in the database in the end, util Date type is mostly preferred when working with JPA. The util Date provides a standardized way to work with dates in JPA. The util Date provides date and time with millisecond precision.

The @temporal annotation is used in conjunction with the Date type. The @temporal annotation has required a single parameter of type TemporalType. There are three Temporal types DATE, TIME, and TIMESTAMP. Let's look at each one of them.

Let's annotate the member variable with @temporal with TemporalType as Date.

Check out the previous posts to know how to set up the Java project with JPA and database.

@Entity
@Table(name = "Student_Table")
public class Student {
    @Id
    @GeneratedValue
    private int id;
    private String admission_no;
    @Column(name = "student_name")
    private String name;
    private int age;
    @Temporal(TemporalType.DATE)
    private Date dob;
}

Now persisting the student entity in the database.

public class Main {
    public static void main(String[] args) {
        EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("myPersistenceUnit");
        EntityManager entityManager = entityManagerFactory.createEntityManager();
        Student student1 = new Student();
        student1.setName("Sohail Shah");
        student1.setAge(18);
        student1.setAdmission_no("1234");
        student1.setDob(new Date());

        EntityTransaction transaction = entityManager.getTransaction();
        transaction.begin();
        //persist the student entity
        entityManager.persist(student1);
        transaction.commit();
        entityManager.close();
        entityManagerFactory.close();
}

The TemporalType.DATE persists only the date. Now check the database for the values.

To persist the timestamp we can change the TemporalType to TIMESTAMP.

@Entity
@Table(name = "Student_Table")
public class Student {
    @Id
    @GeneratedValue
    private int id;
    private String admission_no;
    @Column(name = "student_name")
    private String name;
    private int age;
    @Temporal(TemporalType.TIMESTAMP)
    private Date dob;
}

After persisting the student entity, check the database for the values. The date of birth field contains the date with time.

To persist only the time change the TemporalType to TemporalType.TIME

@Entity
@Table(name = "Student_Table")
public class Student {
    @Id
    @GeneratedValue
    private int id;
    private String admission_no;
    @Column(name = "student_name")
    private String name;
    private int age;
    @Temporal(TemporalType.TIME)
    private Date dob;
}

Persist the student entity and in the database, we can see only the time is persisted.

Enumeration

To persist enumeration values to database columns using JPA is to use the @Enumerated annotation. The @Enumerated annotation tells the JPA to map the enum value to the database.

Let's add a member variable student type to our student entity which is an enum.

public enum StudentType {
    SCHOLARSHIP,
    NON_SCHOLARSHIP
}

@Entity
@Table(name = "Student_Table")
public class Student {
    @Id
    @GeneratedValue
    private int id;
    private String admission_no;
    @Column(name = "student_name")
    private String name;
    private int age;
    @Temporal(TemporalType.TIME)
    private Date dob;
    private StudentType studentType;
}

Now annotate the student type member variable with @Enumerated

    @Enumerated
    private StudentType studentType;

That's it, now we can persist the student entity and check the database.

        Student student1 = new Student();
        student1.setName("Sohail Shah");
        student1.setAge(18);
        student1.setAdmission_no("1234");
        student1.setDob(new Date());
        student1.setStudentType(StudentType.SCHOLARSHIP);

The value of student type in the database column is set to 0. That's because by default enum type is set to ordinal. When enum type is set to ordinal, JPA persists the position of the enum in the enum class. In our example, The StudentType enum class has two constant strings, SCHOLARSHIP with position 0 and NON_SCHOLARSHIP with position 1. Since we set the student type to StudentType.SCHOLARSHIP it's position was persisted.

This behaviour can be changed by setting the EnumType as String in the @Enumerated annotation parameter. Let's do it now.

    @Enumerated(EnumType.STRING)
    private StudentType studentType;

Now persist the student entity and check the database.

The actual value of the string is saved to the database.
Use the enum type in annotation parameter as per your needs, either as EnumType.STRING or EnumType.ORDINAL.

But be careful with using enum in your entities. If the enum type is set to ordinal, you cannot change the positions of constant strings in the enum class. If the enum type is set to string then you can change the position but cannot change the spellings of it. Doing both will lead to data inconsistencies in the database.

Follow me on : Twitter, LinkedIn, GitHub, Linktree

Know The JPA Persistence.xml File

Sohail Shah — Wed, 21 Jun 2023 07:01:32 +0000

In the previous posts, we set up the Java project and connected it to a database with JPA, and hibernate. Let's look back on the persistence.xml file we created and understand it in more detail.

The location of this file is src -> META-INF -> persistence.xml


 XML
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
             version="2.0">
    <persistence-unit name="myPersistenceUnit" transaction-type="RESOURCE_LOCAL">
        <properties>
            <!-- Database connection properties -->
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="sa"/>
            <property name="javax.persistence.jdbc.password" value=""/>

            <!-- Hibernate properties -->
            <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
            <property name="hibernate.show_sql" value="true"/>
            <property name="hibernate.format_sql" value="true"/>
            <property name="hibernate.hbm2ddl.auto" value="create"/>
        </properties>
    </persistence-unit>
</persistence>

The main node/ tag is the <persistence> & everything goes inside it.

The next node is <persistence-unit>. We can create multiple persistence-unit nodes inside the persistence node. Each persistence-unit node has its name and transaction type. In our case the name is "myPersistenceUnit" and the transaction type is set to RESOURCE_LOCAL.

There are typically three types of transactions

JTA (Java Transaction API) - used in Java EE environments
RESOURCE_LOCAL - used in Java SE environments
AUTO - determines the environment automatically

Next is defining the properties of our persistence unit. First, we have provided the database connection properties. Let's look at them individually.

url - It is the database connection string


 XML
<property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>

driver - The database driver for the respective database used in the application


 XML
<property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>

user - username for the database connection


 XML
<property name="javax.persistence.jdbc.user" value="sa"/>

password - password for the database connection


 XML
<property name="javax.persistence.jdbc.password" value=""/>

All the properties come from the javax.persistence meaning these are JPA property names, not the hibernate properties.

Next, we have defined the hibernate properties. These properties define the working behavior of the hibernate implementation. Let's look at them individually.

Dialect :

The dialect here means the SQL query grammar used by the JPA implementation uses when connecting to the database. Even though all the databases use SQL, there are some minor differences in the grammar. So we have to specify the dialect for the database we are using.

For example, if we are using PostgreSQL we set the dialect like this


 XML
<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>

For MySQL database


 XML
<property name="hibernate.dialect" value="org.hibernate.dialect.MYSQLDialect"/>

show_sql :

If this property is set to true when we run our application and make database operations we can actually see the SQL queries written in the console. This is useful mainly for development purposes

format-sql :
If this property is set to true, then it formats the SQL queries in the console. Again this can be useful for development purposes.


 XML
 <property name="hibernate.format_sql" value="true"/>

hbm2ddl.auto :

This property defines the auto behaviour of the hibernate when converting JPA entities to ddl (data definition language). Here it is set to create-drop which sets the behaviour to drop the database schema and tables and create new schemas based on the JPA entities. It is typically used in development only as we don't want to drop our existing tables from the database.


 XML
<property name="hibernate.hbm2ddl.auto" value="create"/>

Some different behaviours we can set the auto to are:

i. validate - Validates the schema against the mapping metadata
ii. update - Updates the schema based on the mapping metadata
iii. create - Creates a new schema from scratch based on the mapping metadata
iv. none - Disables automatic schema generation and update

There are many other properties and tags present which can be used to define the behaviour of our persistence unit, but these are enough to get started with your application running.

Follow me on : Twitter, LinkedIn, GitHub, Linktree