Skip to content

Commit e6c340c

Browse files
committed
Multiple database connections using getConnectionToken
1 parent 566fd5b commit e6c340c

File tree

2 files changed

+51
-0
lines changed

2 files changed

+51
-0
lines changed

content/techniques/mongo.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -222,6 +222,23 @@ export class CatsService {
222222
}
223223
```
224224

225+
It's also possible to inject any `Connection` to the providers:
226+
227+
```typescript
228+
@Module({
229+
providers: [
230+
{
231+
provide: CatsService,
232+
useFactory: (catsConnection: Connection) => {
233+
return new CatsService(catsConnection);
234+
},
235+
inject: [getConnectionToken('cats')],
236+
},
237+
],
238+
})
239+
export class CatsModule {}
240+
```
241+
225242
#### Hooks (middleware)
226243

227244
Middleware (also called pre and post hooks) are functions which are passed control during execution of asynchronous functions. Middleware is specified on the schema level and is useful for writing plugins ([source](https://mongoosejs.com/docs/middleware.html)). Calling `pre()` or `post()` after compiling a model does not work in Mongoose. To register a hook **before** model registration, use the `forFeatureAsync()` method of the `MongooseModule` along with a factory provider (i.e., `useFactory`). With this technique, you can access a schema object, then use the `pre()` or `post()` method to register a hook on that schema. See example below:

content/techniques/sql.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -591,6 +591,23 @@ export class AlbumsService {
591591
}
592592
```
593593

594+
It's also possible to inject any `Connection` to the providers:
595+
596+
```typescript
597+
@Module({
598+
providers: [
599+
{
600+
provide: AlbumsService,
601+
useFactory: (albumsConnection: Connection) => {
602+
return new AlbumsService(albumsConnection);
603+
},
604+
inject: [getConnectionToken('albumsConnection')],
605+
},
606+
],
607+
})
608+
export class AlbumsModule {}
609+
```
610+
594611
#### Testing
595612

596613
When it comes to unit testing an application, we usually want to avoid making a database connection, keeping our test suites independent and their execution process as fast as possible. But our classes might depend on repositories that are pulled from the connection instance. How do we handle that? The solution is to create mock repositories. In order to achieve that, we set up [custom providers](/fundamentals/custom-providers). Each registered repository is automatically represented by an `<EntityName>Repository` token, where `EntityName` is the name of your entity class.
@@ -1160,6 +1177,23 @@ export class AlbumsService {
11601177
}
11611178
```
11621179

1180+
It's also possible to inject any `Sequelize` instance to the providers:
1181+
1182+
```typescript
1183+
@Module({
1184+
providers: [
1185+
{
1186+
provide: AlbumsService,
1187+
useFactory: (albumsSequelize: Sequelize) => {
1188+
return new AlbumsService(albumsSequelize);
1189+
},
1190+
inject: [getConnectionToken('albumsConnection')],
1191+
},
1192+
],
1193+
})
1194+
export class AlbumsModule {}
1195+
```
1196+
11631197
#### Testing
11641198

11651199
When it comes to unit testing an application, we usually want to avoid making a database connection, keeping our test suites independent and their execution process as fast as possible. But our classes might depend on models that are pulled from the connection instance. How do we handle that? The solution is to create mock models. In order to achieve that, we set up [custom providers](/fundamentals/custom-providers). Each registered model is automatically represented by a `<ModelName>Model` token, where `ModelName` is the name of your model class.

0 commit comments

Comments
 (0)