spring JPA entities: cheat sheet

Week 10 of coding bootcamp was marked by lots of junk food, a sleepless Sunday night from drinking my coffee too late, and oh yeah learning about Spring JPA entities. Learning them felt like mental gymnastics for me. Now that my brain has shakily landed from its endless flips and rumination, I wanted to share my basic understanding of the how behind each. 😅

Table of Contents

1. 🌸 One to Many

2. 🌷 One to One

3. 🌼 Many to Many

One to Many

Below we have two entities from the basic backend framework of an ecommerce’s app’s backend. A customer has a one to many relationship with orders. In other words, a customer can buy multiple orders.

*Note: Even though we don’t see a list of orders or the customer object - we can access that relationship programmatically via JPA, as discussed above.

Here are how the Order and Customer Table look respectively on Postgres.

@JsonIgnore

The @JsonIgnore is to prevent “looping” (aka circular dependency) when we display the data. For example, when we made a request to get orders tied to a customer, without JSON, it would show the order, then the customer, which then shows the customer field info and then calls the order field which then calls the customer, ad infinitum.

With @JsonIgnore- only the Order information would show when making that get request.
When deciding where to place @JsonIgnore- you can think of it as we don’t need to show the customer when querying orders, but it would be more helpful to show the orders when querying a customer. An alternative way of approaching that thought process is: we put @JsonIgnore over the customer field, because a customer can exist without orders but not vice versa.

Owning Table

Orders is the owning table, which means any changes to the relationship, such as adding or removing orders for a customer, should be made through the customer field in the Order entity.) The owning side is also where the relationship is persisted in the database; that is the owning side is the one that owns the foreign key in the relationship.

We chose orders as the owning side, because of operational logic. You typically create orders and associate with customers, not the other way around.

The example code block shows how we add an order to a customer. order represents the new order we are adding (sent via the request body in the API call @PostMapping("/customers/{id}/orders")).

 public Customer addOrderToCustomer(Integer id, Order order) throws Exception {
        Customer customer = customerRepository.findById(id).orElseThrow(() -> new Exception("Customer not found"));
        order.setCustomer(customer);
        orderRepository.save(order);
        return customer;
    }

Notice how the updates in the code are done via the order’s side. The customer that has made the order is set to the customer field in the Order entity. This Order instance that now has the respective customer tied to it is then saved (persisted) to the Order database.

Bidirectional

As a side note, as cascade persist is not used above, you can set the order on the customer side as well to allow for bidirectional navigation. Cascade persist means that operations on say a customer entity would persist to the associated order entities (i.e. if you deleted a customer, then the associated customer would aso delete) …however, in our case- as we are primarily accessing orders from the orders side (i.e. we typically retrieve orders and associate them with customers), then we don’t need that bidirectional code added.

Note:

Keep in mind, for unidirectional one-to-many relationships, in most cases- you have to set both entities "to each other", in other words for example set a team to a player, and player to a team. On the other hand, many-to-many relationships are bidirectional and that means if you set a post to have a tag, you don't need to set the post to the tag- since JPA handles that on the backend (made possible by the associations between both entities via the join table).

One to One

Below we see how each record in our Address entity is associated with one record in the Customer entity., and vice versa. That is, in our hypothetical scenario: each customer can have one address, and one address can belong to one customer.

All the annotations are handled on the Customer entity side:

• @OneToOne annotation in our Customer entity above private Address address means that one customer instance has one address
• CascadeType.ALL in our Customer entity means that for any actions taken on a Customer instance, should also be applied to the Address. For example, if a customer is deleted, then its respective address will also be deleted. Likewise, if a customer is created, then it will be expected to have an address added.
• @JoinColumn annotation indicates the address_id is the foreign key.
• nullable=false means the address_id can’t be null, or in other words each customer needs to have an address associated with it. When creating or updating a user, it must have an address. -unique=true means that for each customer, they must have a unique address.

This screenshot below shows the Customer table in Postgres, and you can see the foreign key address_id as the first column- essentially allowing this table to “link” to the Address table.

Many to Many

Below we see a relationship where one order can have multiple products (i.e. TV, sofa, etc), and one product can have many orders. In other words, orders and products have a many to many relationship.

*This below screenshot shows the Join Table that is actually created in Postgres from that @JoinTable annotation.

Side note:

• On the Order table: =new ArrayList<> initializes the list of products with an empty array list, so that as products are added to an order, that array list is updated. This ensures that the products field is not null even if no products are associated with that order at initialization time.
• On the Product table: =new ArrayList<> initializes the list of orders with an empty array list, so that as new orders are made with that product, then those orders can be added in. This ensures that the orders field is not null even if no orders are associated with that product at initialization time.