Persisting Data in the Database

Overview

Now that our environment is ready, we’ll add a new repository to save the Pomodoro application data into SQLite. Currently, the application supports only the inMemory repository. When we add more repositories, we need to provide a way for our users to choose how to store data. We can do this at compile time or runtime.

Providing this choice at runtime makes our application more flexible, allowing users to choose which data store to use for every execution. To do this, we need to compile our application with support for all required data stores and allow the user to choose one, using command-line parameters or configuration options.

We can also compile the application with support for a specific data store, creating a binary file with fewer dependencies and a smaller size. The application will be less flexible but more efficient. To do this, we include specific files in our build according to different criteria. The criteria depend on our requirements. For example, we can include different data stores for testing, production environments, or when compiling for an operating system that doesn’t support a required dependency.

For this example, we’ll take the second approach and define the data store at compile time so we can build this application and test it using the inMemory repository in case we are unable to install SQLite. We’ll do this by including specific files in our build using build tags.

Updating the repository

Since saving the data to the database gives the application more functionality, let’s make it the default option, so when we build the application without any tags, it will include the SQLite repository and not the inMemory one. When we want to build the application with support for inMemory storage, we’ll use the build tag inmemory.

We update the files related to the inMemory repository with the inmemory build tag by adding the line // +build inmemory at the top of each file. First, we edit pomodoro/ repository/inMemory.go:

It’s critical to leave a blank line between the build tag comment and the package definition. If we don’t, Go will consider it to be a regular comment and will ignore the build tag.

Next, we include the same build tag for the remaining two files: pomodoro/inmemory_test.go and cmd/repoinmemory.go:

Updating the sqlite3.go file

We update the sqlite3.go file in the repository package directory pomodoro/ repository, which will contain the code for the SQLite repository. Let’s open the file in our editor and add the build tag to include this file when the tag inmemory isn’t available. We use the character ! to negate the tag:

Then we add the package definition and the import ...