Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

createTypeOrmProviders should inject EntityManager instead of Connection #1819

Closed
1 task done
edeesis opened this issue Nov 27, 2023 · 1 comment
Closed
1 task done
Labels

Comments

@edeesis
Copy link

edeesis commented Nov 27, 2023

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

createTypeOrmProviders currently injects getConnection and resolves the repositories directly from the connection. However, there are certain scenarios when you'd want to resolve the repository from the EntityManager, such as when running in a transaction.

Describe the solution you'd like

I'm proposing changing the createTypeOrmProviders function to inject the EntityManager and use that to initialize the repositories.

export function createTypeOrmProviders(
  entities?: EntityClassOrSchema[],
  dataSource?: DataSource | DataSourceOptions | string,
): Provider[] {
  return (entities || []).map((entity) => ({
    provide: getRepositoryToken(entity, dataSource),
    useFactory: (entityManager: EntityManager) => {
      const enitityMetadata = dataSource.entityMetadatas.find((meta) => meta.target === entity)
      const isTreeEntity = typeof enitityMetadata?.treeType !== 'undefined'
      return isTreeEntity 
        ? entityManager.getTreeRepository(entity)
        : entityManager.connection.options.type === 'mongodb'
          ? entityManager.getMongoRepository(entity)
          : entityManager.getRepository(entity);
    },
    inject: [getEntityManagerToken(dataSource)],
    /**
     * Extra property to workaround dynamic modules serialisation issue
     * that occurs when "TypeOrm#forFeature()" method is called with the same number
     * of arguments and all entities share the same class names.
     */
    targetEntitySchema: getMetadataArgsStorage().tables.find(
      (item) => item.target === entity,
    ),
  }));
}

Teachability, documentation, adoption, migration strategy

This should theoretically be a non-breaking change to all users of the library. We're merely changing which object we're calling getRepository on. In fact, DataSource's getRepository method just proxies to the manager anyway.

What is the motivation / use case for changing the behavior?

The instance of manager changes when you open a transaction. That manager instance has to be used to generate the repository, otherwise the transaction is ignored.

Currently, the only method for working around this is overriding each Repository provider. This would allow someone to override the EntityManager and then all repositories created will use that manager instance.

edeesis added a commit to edeesis/nestjs-typeorm that referenced this issue Nov 27, 2023
…etEntityManagerToken instead of getConnectionToken

closes nestjs#1819
edeesis added a commit to edeesis/nestjs-typeorm that referenced this issue Nov 27, 2023
…se getEntityManagerToken instead of getConnectionToken

closes nestjs#1819
edeesis added a commit to edeesis/nestjs-typeorm that referenced this issue Nov 27, 2023
…se getEntityManagerToken instead of getConnectionToken

closes nestjs#1819
edeesis added a commit to edeesis/nestjs-typeorm that referenced this issue Nov 27, 2023
This change will make Repository generation use getEntityManagerToken instead of getConnectionToken

closes nestjs#1819
@kamilmysliwiec
Copy link
Member

Let's track this here #1820

edeesis added a commit to edeesis/nestjs-typeorm that referenced this issue Jan 8, 2024
This change will make Repository generation use getEntityManagerToken instead of getConnectionToken

closes nestjs#1819
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants