-
Notifications
You must be signed in to change notification settings - Fork 215
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
Labels
Comments
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
12 tasks
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
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
Is there an existing issue that is already proposing this?
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.
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.
The text was updated successfully, but these errors were encountered: