Project Statement phase 3

Week 3: Phase 3: Data Persistence and Advanced Queries

Topic

Extending the Simple Notification Service with a data persistence layer using Spring Data JPA and Hibernate. This phase focuses on advanced querying techniques and entity relationships.

Goal of the Project

• To apply fundamental concepts of JPA and Hibernate to persist application data.

• To practice building and using a repository layer for data access.

• To understand and implement advanced query methods using various JPA/Hibernate features.

• To establish and manage relationships between entities, including optimizing data retrieval.

Description

This document outlines the third phase of the Simple Notification Service project. It assumes you have successfully completed Phases 1 and 2, which established the core Spring Boot application, a REST endpoint, scheduled tasks, and basic configuration.

In this phase, you will transform the application from an in-memory console-based service to a fully persistent one. The primary goal is to save all notifications to a database and retrieve them using a variety of advanced querying techniques. This will provide a deeper understanding of Spring Data JPA and Hibernate.

Phase 3: Data Persistence and Advanced Queries (JPA/Hibernate)

This phase extends the application to persist notifications and introduces advanced data access techniques with specific service requirements.

• JPA and Hibernate Integration:

• Configure application.properties to connect to a database (e.g., H2 or PostgreSQL) and enable SQL logging to monitor generated queries.

• Update your existing Notification class to be a JPA @Entity with an automatically generated UUID as the primary key. This entity should have message, timestamp, recipient, and channel fields. The channel field can be an enum (e.g., EMAIL, SMS, PUSH_NOTIFICATION) to represent the delivery method.

• Add the necessary hibernate-spatial and JTS dependencies if opting for PostgreSQL with Postgis.

• Repository Layer:

• Create a NotificationRepository interface extending JpaRepository<Notification, UUID> to gain basic CRUD operations.

• This repository will serve as the primary data access layer for all subsequent tasks.

• You will also need to create a RecipientRepository interface extending JpaRepository<Recipient, UUID> to manage the data persistence for the Recipient entity.

• Query Creation from Method Names:

• Implement a new REST endpoint, GET /api/notifications/search, which accepts message and optional startDate and endDate parameters.

• Create a repository method with the signature List findByMessageContainingIgnoreCaseAndTimestampBetween(String message, Instant startDate, Instant endDate) to fulfill this requirement.

• HQL and Native Queries:

• Add a repository method using the @Query annotation with HQL to find all notifications with a message that matches a given pattern and were sent in the last 24 hours.

• Implement a separate repository method using @Query(nativeQuery = true) to perform a native SQL query that counts the number of notifications sent in the current month.

• Criteria Queries:

• Create a dedicated NotificationCriteriaService class.

• Implement a method within this service that takes optional parameters for message, minTimestamp, maxTimestamp, channel, and recipient. The method should use the JPA Criteria API to dynamically build a query based on the provided parameters.

• EntityGraphs and Relations:

• Create a new @Entity class named Recipient with fields for id, name, email, phoneNumber, and pushNotificationId.

• Establish a @ManyToOne relationship from the Notification entity to the Recipient entity, allowing each notification to be linked to a single recipient.

• Create a new repository method in NotificationRepository that uses @EntityGraph to fetch a list of notifications and their associated Recipient in a single query, demonstrating how to avoid the N+1 select problem.

• Postgis and JTS:

• Add a Point field from the JTS library to your Recipient entity to store its location.

• Create a new POST /api/notifications/send-to-area endpoint that accepts a notification message and a bounding box defined by minLat, minLon, maxLat, and maxLon.

• Implement a new native query repository method in RecipientRepository that uses Postgis functions to find all recipients within the specified bounding box. The service should then iterate through these recipients and send a notification to each one (i.e., save a new Notification entity associated with each Recipient).

Deliverables or Expectations

• The existing application from Phases 1 and 2 should be extended to save notifications to and retrieve them from a database.

• New entities (Notification and Recipient) with all their specified fields and the @ManyToOne relationship must be correctly implemented.

• The application should expose the new GET /api/notifications/search and POST /api/notifications/send-to-area REST endpoints.

• Both a NotificationRepository and a RecipientRepository should be created, extending JpaRepository.

• The NotificationRepository must demonstrate a method-based query, an HQL query, a native SQL query, and an optimized query using @EntityGraph.

• A dedicated service method must use the JPA Criteria API to dynamically query notifications based on the optional parameters message, minTimestamp, maxTimestamp, channel, and recipient.

• The application must be able to find recipients within a geographic bounding box and send them notifications.

• The project structure should be clean, and the code should adhere to good coding practices.

• The README.md file must be updated to explain the new database setup, build process, and how to test all the new REST endpoints.

Keywords

Spring Framework | Spring Boot | Spring Data JPA | JPA | Hibernate | @Entity | @Repository | @Query | HQL | Native Query | Criteria API | EntityGraph | @OneToMany | Postgis | JTS