Support literal repository change in TypeORM@next
Opened this issue · 6 comments
Repository is no longer a class but an object literal since typeorm/typeorm@ba4bebe and this breaks BaseRepository.
Wow... on the surface this seems like a real deal breaker ): Do you have any ideas how to tackle this one?
The whole idea in this library is to always get the right entityManager from the context, by overriding the getter method... now when it is a literal member and not a function, it seems a bit hard.
Will be glad to hear ideas...
Perhaps we can patch the create() method in EntityManagerFactory. Then, for each manager instance created, override the manager's getRepository() method and add getter/setter to the repository's manager property to return the manager from the cls context.
Is this something I should worry about when evaluating this library for a new project? I appreciate your work, but i don't want to create technical debt right from the start. 🤔
@matomesc I think the solution is the correct one. I was looking at the code before you mentioned it, but did not have the chance to write a comment.
@buxel - This library was implemented for personal usage and was published as a contribution for the community.
I am a bit off now for personal reasons. Will appreciate PRs...
Cheers
Your contribution is much appreciated. I've put this issue into our project backlog, but also had to put transactions on hold because i'll have to focus on a different project starting next week.
Any chance someone's started working on this? I'm not sure when TypeORM@next will land but it'd be great to have this worked out by then.
@buxel we had this discussion at work and ultimately decided to move ahead with using this library. While we are concerned about incompatibility with TypeORM@next, the value that it provides now (we're using this for transaction rollbacks in tests ala Database Cleaner) outweigh the risks of difficulty migrating in the future, so we're just taking on that debt. It looks like the next version of TypeORM contains some serious breaking changes so I don't think that incompatibility with this library will be the deciding factor in when or whether we upgrade, anyway.