3.2.3 Annotating the domain for persistence

The only other thing we’ll need to do is annotate our domain classes so that Spring Data JDBC will know how to persist them. Generally speaking, this means annotating the identity properties with @Id—so that Spring Data will know which field represents the object’s identity—and optionally annotating the class with @Table.

For example, the TacoOrder class might be annotated with @Table and @Id as shown in the following code.

Listing 3.15 Preparing the Taco class for persistence

package tacos;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

import javax.validation.constraints.Digits;
import javax.validation.constraints.NotBlank;
import javax.validation.constraints.Pattern;

import org.hibernate.validator.constraints.CreditCardNumber;
import org.springframework.data.annotation.Id;
import org.springframework.data.relational.core.mapping.Table;

import lombok.Data;

@Data
@Table
public class TacoOrder implements Serializable {

  private static final long serialVersionUID = 1L;

  @Id
  private Long id;

  // ...

}

The @Table annotation is completely optional. By default, the object is mapped to a table based on the domain class name. In this case, TacoOrder is mapped to a table named "Taco_Order". If that’s fine for you, then you can leave the @Table annotation off completely or use it without parameters. But if you’d prefer to map it to a different table name, then you can specify the table name as a parameter to @Table like this:

@Table("Taco_Cloud_Order")
public class TacoOrder {
  ...
}

As shown here, TacoOrder will be mapped to a table named "Taco_Cloud_Order".

As for the @Id annotation, it designates the id property as being the identity for a TacoOrder. All other properties in TacoOrder will be mapped automatically to columns based on their property names. For example, the deliveryName property will be automatically mapped to the column named delivery_name. But if you want to explicitly define the column name mapping, you could annotate the property with @Column like this:

@Column("customer_name")
@NotBlank(message="Delivery name is required")
private String deliveryName;

In this case, @Column is specifying that the deliveryName property will be mapped to the column whose name is customer_name.

You’ll also need to apply @Table and @Id to the other domain classes. This includes @Ingredient.

Listing 3.16 Preparing the Ingredient class for persistence

package tacos;

import org.springframework.data.annotation.Id;
import org.springframework.data.domain.Persistable;
import org.springframework.data.relational.core.mapping.Table;

import lombok.AccessLevel;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@Table
@AllArgsConstructor
@NoArgsConstructor(access=AccessLevel.PRIVATE, force=true)
public class Ingredient implements Persistable<String> {

  @Id
  private String id;

  // ...

}

...adn Taco.

Listing 3.17 Preparing the Taco class for persistence

package tacos;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;

import org.springframework.data.annotation.Id;
import org.springframework.data.relational.core.mapping.Table;

import lombok.Data;

@Data
@Table
public class Taco {

  @Id
  private Long id;

  // ...

}

As for IngredientRef, it will be mapped automatically to the table whose name is "Ingredient_Ref", which is perfect for our application. You can annotate it with @Table if you want, but it’s not necessary. And the "Ingredient_Ref" table has no identity column, so there is no need to annotate anything in IngredientRef with @Id.

With these small changes, not to mention the complete removal of the JdbcIngredientRepository and JdbcOrderRepository classes, you now have a lot less persistence code. Even so, the repository implementations that are generated at runtime by Spring Data still do everything that the repositories using JdbcTemplate did. In fact, they have potential for doing even more, because the two repository interfaces extend CrudRepository, which offers a dozen or so operations for creating, reading, updating, and deleting objects.