Kesha Williams introduces the course project, TrackZilla, that was developed in part 1 of the course.
- [Instructor] We will build upon the bug-tracking case study, TrackZilla, which was developed in the JPA part one course in the library. TrackZilla is a cloud-based web application that tracks defects and enhancement requests for software applications. It uses the Java Persistence API to interact with its H2 in-memory database. It's important to understand the application architecture and the tools you will use like the H2 database and Postman. Before we look at the code, let's review a diagram of the application architecture.
The TrackZilla application is a Spring-based application that has domain, service, and data access layers. The persistence data store is an H2 database. The TrackZilla application currently manages application, ticket, and release entities using the entity manager. Currently there are relationships between each entity. First, an application belongs to 0 or 1 release and a release can have zero or many applications. Next, a ticket belongs to one application and an application can have zero or many tickets.
Finally, a ticket belongs to 0 or 1 release and a release can have zero or many tickets. So let's take a look at the application code. I've opened the TrackZilla application in IntelliJ and navigated to the TrackZilla controller file. So underneath the controller folder, that's where you'll find the file. Now the TrackZilla application has a Spring MVC RestController here on line 18, which simplifies creating Restful web services. The Restful web service controller returns object data that is written directly to the HTTP response as JSON.
Now the request mapping on line 19 is one of the most common annotations used in Spring web applications and maps HTTP requests to the correct handler method in the RestController. The root of all requests will be tza, which is of course, short for TrackZilla. Each handler method maps to a specific HTTP request. Let's scroll through and call out a few important methods. So on line 41, we have our getApplicationById method, which takes the application ID as a path parameter.
This allows us to limit the return to one specific application. Let's navigate down to line 67. And this should be our getAllTickets method. And so this method returns a list of all tickets. And then we have the typical remaining CRUD, create, read, update, delete operations. So let's go back to line 32. And on this line, we see our addApplication method. So this allows us to add a new application to the system.
And now on line 48, let's look at our updateApplication method, which allows us to update an existing application should we need to modify existing fields. And lastly, let's look at our deleteApplication here on line 54. So this allows us to delete an existing application from the system should it no longer be needed. So now TrackZilla has a data access object layer. So this DAO layer makes it easy to work with JPA for data access.
So let's navigate to ApplicationDAO. So if you go to the DAO folder and double-click on ApplicationDAO, you should see our file. Now since we are using JPA, we will need access to an entity manager. The easiest way to access an entity manager is to have the resource dependency injected using the @PersistenceContext annotation. We see this here on lines 19 and on line 20. So now that we have an entity manager object, we can use it to interact with the database.
So we've implemented the CRUD methods here. So notice on line 23, we have our addApplication method. And it uses the persist method of the entityManager to save the entity to the database. Next on line 36, we have our getApplicationById method. And notice it uses the find method of the entityManager. We also have on line 41, our updateApplication. And notice, it uses the flush method of the entityManager to update the attributes of an existing application.
On line 50, we have our deleteApplication method. And notice, it uses the remove method of the entityManager to remove an existing application. And lastly, we have a helper method back on line 28. It's called applicationExists and it confirms the application doesn't exist before adding it to the database. So now let's look at the domain entities. So underneath the entity folder you will see three. So TrackZilla has three domain entities that represent the business data captured by the system.
Each entity class is mapped to a database table. So application is defined in application.java. This domain entity represents the application that a bug or enhancement request or ticket will be tracked against.
- Inheriting entities
- Mapping a superclass
- Querying through JPA
- Defining query parameters
- Creating a compile-time named query
- Using native queries
- Creating stored procedures
- Using the Criteria API
- Refining query results
- Switching between persistence providers