Martin Adámek
Martin Adámek
Uh, why? I don't see how an inverse side should be a limiting factor for this. This is something to fix, not do document.
I took a closer look, and the whole implementation of the dataloader filters feels quite duplicated, the EntityLoader already implements all those things, in the correct way (without the need...
I guess we can close this one, the only missing piece is considering if we want to drop some of the languages.
I would rather not add this, I am not very happy with the way people overuse this method in the first place. Let's see what others think, will leave it...
> without em injection But why? You should inject it and use it where appropriate instead of flushing via repositories. They are extension points, thin wrappers around EM without any...
I kinda doubt this is something fixable from this package, its nest DI that is responsible for the injection.
Just look at what the PR does, how come it would be connected to nest DI not injecting a dependency? If it is, it still sounds like a nestjs bug...
> [This line seems suspicious to me.](https://github.com/mikro-orm/nestjs/blob/master/src/mikro-orm-core.module.ts?rgh-link-date=2022-12-31T15%3A42%3A17Z#L100) if someone sets up a useFactory in the async registration that has a value pissed to it, like the ConfigServive, but it's called...
That would be great!
Both should work, the one from `core` as well as the driver-specific implementation. They should resolve to the same - during runtime, it will be always the driver-specific implementation, but...