18.3. Creating a One-to-Many Relationship¶

18.3.2.2.1. Update 1: Optional categoryId Parameter¶

In order to filter events by category, we need the ID of a category to filter by. The handler now has a new parameter:

@RequestParam(required = false) Integer categoryId

This allows requests to URLs like /events?categoryId=1. By specifying required = false we are telling Spring that it should call this handler for requests to the path /events even if no such ID is specified. This allows us to preserve our existing behavior that lists all events at /events. If no categoryId is specified in the request, then the categoryId parameter will be null when the handler is called.

18.3.2.2.2. Update 2: null Check¶

Much of the method consists of a large if/else if/else block.

Before filtering by category, we check for the existence of the categoryId parameter. The first part of the conditional block is:

32
33
34
35

if (categoryId == null) {
   model.addAttribute("title", "All Events");
   model.addAttribute("events", eventRepository.findAll());
}

If no categoryId is passed in, we carry out the same behavior as before, passing all events into the view.

18.3.2.2.3. Update 3: Ensuring the Category Object Exists¶

If the conditional check above fails, then we have a non-null categoryId. However, this does not guarantee that an object with the given ID exists in the database. We must manually check for the existence of such an object.

Here’s our conditional block with the next piece added:

32
33
34
35
36
37
38
39
40
41
42

if (categoryId == null) {
   model.addAttribute("title", "All Events");
   model.addAttribute("events", eventRepository.findAll());
} else {
   Optional<EventCategory> result = eventCategoryRepository.findById(categoryId);
   if (result.isEmpty()) {
         model.addAttribute("title", "Invalid Category ID: " + categoryId);
   } else {
         // TODO
   }
}

Line 36 queries our repository for a category object with the given ID. Notice that the findById method returns not an EventCategory object, but something of type Optional<EventCategory>. Huh?

Referring to the documentation for the CrudRepository.findById method, we see that it returns an Optional instance. We don’t currently know what the heck that is, but referring to the documentation for Optional describes how to use this class.

Essentially, by returning an Optional<EventCategory> object, the findById method is taking into account the exact situation we are in, that an object with such an ID may not exist. An Optional object can be thought of as a container for the results of our query. If such an object does exist, we can get it using Optional.get(). Otherwise, Optional.isEmpty() will return true.

On lines 37-38 we use this fact to check to see if an EventCategory object was found. If not, we display an error message in the title.

18.3.2.2.4. Update 4: Retrieving Events For the Given Category¶

We are finally ready to consider the full conditional:

32
33
34
35
36
37
38
39
40
41
42
43
44

if (categoryId == null) {
   model.addAttribute("title", "All Events");
   model.addAttribute("events", eventRepository.findAll());
} else {
   Optional<EventCategory> result = eventCategoryRepository.findById(categoryId);
   if (result.isEmpty()) {
         model.addAttribute("title", "Invalid Category ID: " + categoryId);
   } else {
         EventCategory category = result.get();
         model.addAttribute("title", "Events in category: " + category.getName());
         model.addAttribute("events", category.getEvents());
   }
}

Lines 39-42 will only execute if we know for sure that a category with the given ID exists. In this case, we extract the category from the Optional object result using the get() method. Then we create an appropriate title using the category name, and pass the events belonging to the category into the view.

Line 42 is what we have been building up to this entire time. Our category object now has an events field that is populated using the @OneToMany annotation that we added near the beginning of this section, allowing the inverse relationship to be established.

Now, not only do events have categories, but categories know which events they contain.