documentations/examples related to TypeORM are not practical

[kissge]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[ ] Feature request
[x] Documentation issue or request (new chapter/page)
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

It lacks of some fundamental things like CRUD operations. If a developer cannot update RDB using nest, no practical apps can be built with it. How about covering these topics in the docs?

Thanks.

[kamilmysliwiec]

Hey @kissge. I don't think that we should deduplicate all the TypeORM related stuff in our documentation. A tutorial with sample integration might be useful though.

[kissge]

Hi @kamilmysliwiec, OK. I just wanted to be kind to newbies. +1 to a good tutorial...that'll definitely help everyone.

[nobleach]

A good example of where this falls short is from the TypeOrm "how does a person connect to a database" section. We see this:

TypeOrmModule.forRootAsync({
  useFactory: () => ({
    type: 'mysql',
    host: 'localhost',
    port: 3306,
    username: 'root',
    password: 'root',
    database: 'test',
    entities: [__dirname + '/**/*.entity{.ts,.js}'],
    synchronize: true,
  }),
})

With no context, one would have NO idea where this should go. The examples above it show it being placed into app.module.ts but if one naively pastes this snippet, things will break with odd errors.

+1 for an in depth tutorial that's more than just returning an object or array. An actual DB recordset would be awesome!

[lazarljubenovic]

@nobleach I'm confused. Both https://docs.nestjs.com/techniques/database and https://docs.nestjs.com/recipes/sql-typeorm have a clear context. Far from only the snippet you provided. Which section are you talking about?

[nobleach]

Perhaps I'm very wrong here, but the example of app.module.ts from https://docs.nestjs.com/techniques/database, specifies:

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';

@Module({
  imports: [
    TypeOrmModule.forRoot({
      type: 'mysql',
      host: 'localhost',
      port: 3306,
      username: 'root',
      password: 'root',
      database: 'test',
      entities: [__dirname + '/**/*.entity{.ts,.js}'],
      synchronize: true,
    }),
  ],
})
export class ApplicationModule {}

If we were to attempt to take the example further down the page:

TypeOrmModule.forRootAsync({
  imports: [ConfigModule],
  useFactory: async (configService: ConfigService) => ({
    type: 'mysql',
    host: configService.getString('HOST'),
    port: configService.getString('PORT'),
    username: configService.getString('USERNAME'),
    password: configService.getString('PASSWORD'),
    database: configService.getString('DATABASE'),
    entities: [__dirname + '/**/*.entity{.ts,.js}'],
    synchronize: true,
  }),
  inject: [ConfigService],
})

And try to just paste that overtop the former TypeOrmModule example... would that work? Perhaps I'm just misunderstanding, but I was seeing the second snippet above as a contextless example. (Meaning, it's more of an a demonstration of how things could work)

[kamilmysliwiec]

And missing transactions chapter ref https://github.com/nestjs/typeorm/issues/57

[gkolesnikov]

And missing transactions chapter ref nestjs/typeorm#57

Hi @kamilmysliwiec ! Just started using the framework - thank you so much for a very well structured framework in a chaotic world of javascript. I was wondering if there is any progress on the docs/examples regarding typeorm transaction within the framework? This is something I'm trying to implement right now but Typeorm docs are not very helpful with regards to using those with nestjs.

Thanks

[dilame]

Does anyone figure out how to use typeorm transactions?

[jcorkhill]

@dilame I'm looking for information on that as well.

[gaurishanker]

@kamilmysliwiec Use of transactions in nestjs is still not clear and no information is present in docs as well.

[jcorkhill]

I've moved away from Nest, TypeORM, and Inversify, @gaurishanker.

TypeORM does not promote clean architectural practices in that it mixes Data-Access and Business Logic concerns into a single entity, doesn't provide an abstraction over transactions, etc.

Inversify, among others, promotes heavy decorator usage. I find that rather amusing since Dependency Injection, after all, promotes decoupling, and yet by using Inversify and its decorators/property injection, you're now tightly coupled to the IOC Container. In fact, we shouldn't even be using IoC Containers. This is a point that Greg Young heavily pushes.

Finally, NestJS heavily promotes both these systems. It's also rather magical, and magic is dangerous. (Another Greg Young point).

That's not to say Nest is bad. It's certainly not. I've just resolved to implementing three-layer architecture completely by myself at this point, with the Knex Query Builder instead of an ORM.

[arekbal]

In fact, we shouldn't even be using IoC Containers.

1. You seem to be missing the point. Don't push business logic into entities and you will be all fine. Wanna go full-on DDD Aggregates style? Then wrap entities management with your own classes.
2. There is no magic in @Transaction() + @TransactionRepository() decorator or .transaction(ctx => {}). Alternatively, you would need to do a usual try{await trn.commit()}catch{ await trn.rollback()} boilerplate code. Typeorm actually allows you to do transactions... any way you want.
3. Transactions are important part of the database engine. Abstracting them further away, is just dangerous. TypeOrm lets you do this on your own...

So here are some links to transaction docs(not only) in typeorm: typeorm full docs. typeorm transactions docs.