Next challenge: let’s prepare a database that will store all our recipes. We’ll use a Jetbrains Exposed ORM framework coupled with a postgres SQL for it.
First, add necessary dependencies for Exposed to your project.
Add the exposed maven repository to your project level
Versions.kt declare relevant dependencies:
And then use them in your backend module:
Don’t forget to sync your project.
Now that all dependencies are implemented, let’s get down to designing our database.
Our SQL database will have three tables:
Recipes. Every Entity in Exposed DAO has a table which extends
IntIdTable and defines the relationships between variables. Then we can use those relationships to create
Entities and transform them into classes which we can later use in our application.
First, let’s create tables for each class. Add a new package called
storage to your backend package. Then add a package called
exposed inside the storage package. Prepare your project structure for the changes to look like this:
Then add the following tables in relevant files and perform necessary import from
org.jetbrains.exposed along the way:
 We create a table which gets Integer ids automatically and name it “ingredients”. This table holds such properties as name, amount, metric (like in our data class that we defined before). Similarly, the instruction table holds previously defined properties. Recipe table only has a title (read on to find out what to do with instructions and ingredients).
 When we need to create a text property, we use varchar.
 For decimal/double values we use decimal and integer for integer values.
 Now, our recipes actually should have a list of ingredients and instructions. In this simplified database every “ingredient” and “instruction” comes up only in one recipe, but a recipe has a number of ingredients and instructions. Therefore we define a reference in our “ingredients” and “instructions” tables that will point to the recipe where they are used.
 onDelete and onCascade properties tell us how these entries in the table will behave if our parent gets removed. In this case, if the recipe is deleted, the ingredients and instructructions that reference that recipe also get deleted.
Now we can build our entities based on these relations. Add the following code to
 Create an Entity based on the relations in IngredientTable. The Long id property is generated automatically.
 Here we specify the Recipe Entity where the instruction comes up, using a reference to the Recipe table that we’ve created
 Now we can map our database Entity to our class that we defined
earlier so that we can later use it in the application
 The amount is stored as BigDecimal in the database, but we want to use the Double, so we need to convert it
As you can see, now our data classes don’t really match with the entities because of ids. Let’s complete our data classes with ids as follows:
Add an id to
Instruction as well.
Do the same procedure for Instructions. Don’t worry if some things are not resolved at first, we’ll get back to them later.
We only need to create RecipeEntity itself now. Here we’ll need to use those relationships that we’ve defined in Ingredients and Instructions.
 Here we collect all the ingredients and instructions that reference this recipe and create a
 When transforming our entity to a data class, we need to map our
SizedInterable to a
Fix missing imports in all tables and entities, if there are any left - this will make all previous unresolved references go away.
So far so good! We’ve made the necessary preparations to set up our local database.
In the next step we’ll proceed with postgresSQL.