TypeORM By Example: Part 2

We explore an assortment of topics: repositories, existing databases, find options, and the Index decorator.

This article is part of a series starting with TypeORM By Example: Part 1.

The final example for this article is available for download.

Repositories

In the previous article, we executed a method, connection.manager.find(Todo), to find all the todos. TypeORM provides a Repository class that can be used to accomplish the same result.

note: Personally, I believe that repositories only add a marginal amount of value; but will use them never-the-less.

First, we extract out all the todo-specific code out of server.ts.

src / server.ts

And then implement all the todo-specific code in a separate module; observe the todo-specific Repository that we create from the database Connection.

src / todosManager.ts

Working with Existing Databases

Up to this point, we have assumed that we are starting with an empty database. Here we take a sidebar into how to work with existing databases.

There is a tool, typeorm-model-generator, that we can use to generate TypeORM entities from the database itself. In a folder outside of the project we run:

npx typeorm-model-generator -h localhost -d hellodb -u hellouser -x hellouser -e postgres -o . -s public

to generate

todo.ts

Observations:

• We can, with slight modifications, e.g., changing capitalization, replace the Todo.ts we used previously
• In this case we are not managing the database from the application, so we will also want to set migrationsRun to false in ormconfig.json
• In testing this configuration, I observed a bug in the generated file. The generated file does not use the @PrimaryGeneratedColumn() decorator for the id field. At first glance, this does not appear to be a problem, but when used with TypeORM, saving a new todo does not return the newly generated id in the response.

Find Options

So far we have only used the simplest usage of the find method; returning all the todos. The find method has a number of options; the simplest being to return a subset of items.

With the following changes, the readIncomplete endpoint returns only those todos with isComplete equal to false.

src / server.ts

src / todosManager.ts

Detecting Performance Problems

Thinking a bit about how SQL works, we should be concerned that the readIncomplete endpoint will have performance problems (at scale) as we never specified the isComplete field to have an index. Let us confirm our suspicion.

We can enable logging in TypeORM to determine the precise SQL query it uses under the hood.

ormconfig.json

Starting the server and hitting the readIncomplete endpoint we see the following on the console.

We can then take this query and use database tools, e.g., explain, to determine the efficiency of it. We determine that we can improve performance by adding an index on the isComplete field.

note: It is assumed that you understand the basics of SQL database design and how indices help with query performance.

Describing the todo table confirms that there indeed is no index on the isComplete field.

Indices

We create an index on the isComplete field by:

1. Updating Todo.ts

src / entity / Todo.ts

2. Building the application

npm run build-ts

3. Generate the migration

./node_modules/.bin/typeorm migration:generate -n Index

outputing

src / migration / 1535831051738-Index.ts

4. Rebuilding and running the application

npm run build-ts
npm run start

At this point describing the todo table shows the newly created index.

Next Steps

In the next article, TypeORM By Example: Part 3, we continue our exploration with entity validation and revisit the data mapper pattern with custom repositories.

✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.