In our previous example, we created the basic application that will execute a command-line runner by printing a message in the logs. Let's enhance this application by adding a connection to a database.

Earlier, we already added the necessary jdbc and data-jpa starters as well as an H2 database dependency to our build file. Now, we will configure an in-memory instance of the H2 database.

To demonstrate the fact that just by including the H2 dependency in the classpath, we will automatically get a default database, let's modify our StartupRunner.java to look as follows:

public class StartupRunner implements CommandLineRunner {
  protected final Log logger = LogFactory.getLog(getClass());
  @Autowired
  private DataSourceds;
  @Override
  public void run(String... args) throws Exception {
    logger.info("DataSource: "+ds.toString());
  }
}

Now, if we proceed with the running of our application, we will see the name of the DataSource printed in the log, as follows:

2015-03-11 21:46:22.067 org.test.bookpub.StartupRunner :DataSource: org.apache.tomcat.jdbc.pool.DataSource@4…{…driverClassName=org.h2.Driver; … }

So, under the hood, Spring Boot recognized that we've autowired a DataSource dependency and automatically created one initializing the in-memory H2 datastore. It is all good and well, but probably not all too useful beyond an early prototyping phase or for the purpose of testing. Who would want a database that goes away with all the data as soon as your application shuts down and you have to start with a clean slate every time you restart the app?

Let's change the defaults in order to create an embedded H2 database that will not store data in-memory, but rather use a file to persist the data in between application restarts.

Even though, by default, Spring Boot makes certain assumptions about the database configuration by examining the classpath for the presence of supported database drivers, it provides you with easy configuration options in order to tweak the database access via a set of exposed properties grouped under spring.datasource.

The things that we can configure are the url, username, password, driver-class-name, and so on. If you want to consume the datasource from a JNDI location, where an actual instance of a DataSource is being created outside the application, for example by a container, like JBoss or Tomcat, and shared via JNDI, you can configure this using the spring.datasource.jndi-name property. The complete set of possible properties is fairly large, so we will not go into all of them. However, we will cover more options in Chapter 5, Application Testing, where we will talk about mocking data for application tests using a database.

If you want to connect to a regular (non-embedded) database, besides just having the appropriate driver library in the classpath, we need to specify the driver of our choice in the configuration. The following snippet is what the configuration to connect to MySQL would resemble:

spring.datasource.driver-class-name: com.mysql.jdbc.Driver
spring.datasource.url: jdbc:mysql://localhost:3306/springbootcookbook
spring.datasource.username: root
spring.datasource.password:

If we wanted Hibernate to create the schema automatically, based on our entity classes, we will need to add the following line to the configuration:

spring.jpa.hibernate.ddl-auto=create-drop

One can go even further in the abstraction layer and instead of auto-wiring a DataSource object, you could go straight for a JdbcTemplate. This would instruct Spring Boot to automatically create a DataSource and then create a JdbcTemplate wrapping the DataSource, thus providing you with a more convenient way of interacting with a database in a safe way. The code for JdbcTemplate is as follows:

@Autowired
private JdbcTemplate jdbcTemplate;

For the extra curious minds, one can look in the spring-boot-autoconfigure source at an org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration class so as to see the code behind the DataSource creation magic.