-
-
Notifications
You must be signed in to change notification settings - Fork 29
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
feat: support multiple database connections #56
Conversation
…o register with these tokens.
… different MikroORM instance.
…n create a request context for all them when a request is called.
Thanks, will try to take a look during next few days. Worth saying that I don't think we need any breaking changes to support this. This should all be optional and only a new section in the docs should be added, rest should stay unchanged (I mean the examples mainly, and extra decorator usage). Disabling the automatic request context middleware would be a huge breaking change I am not willing to make, but I really believe we can find a way to keep things as they are and just add the new feature. Maybe we could just base this on the |
That sounds good I'll have another tackle at it with your feedback to minimise breaking changes |
@B4nan updated code without breaking changes |
…no longer valid. Also additional README.md improvements.
…getRepository to work without using contextNames
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good so far, found one nit, also the build fails with some TS errors
Co-authored-by: Martin Adámek <banan23@gmail.com>
Yeah when making some more changes to the injection tokens it broken some stuff but I have resolved them now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good, one final nitpick
|
||
export const getEntityManagerToken = (name: string) => `${name}_EntityManager`; | ||
export const InjectEntityManager = (name: string) => Inject(getEntityManagerToken(name)); | ||
export const getSqlEntityManagerToken = (name: string) => `${name}_SqlEntityManager`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doing some refactors and came to this place. do we actually need those? if there will be more EMs, we will pick based on the context name, not on their subtype
will try to remove it, as I believe it shouldn't be needed, one decorator should be enough - users will pick the right subtype on the callsite, there is no inference involved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I wasn't sure if we needed it or not but it does make sense we can use the single EM Injection Token for all the types
The resolves #20
Changes:
getRepositoryToken
andInjectRepository
forMiddleware()
register forMikroOrmModule
so we can register multiple MikroORM's for multiple databases