Motivation
During my early days at university, I remember how quickly I fell in love with object oriented programming and the concepts...
For further actions, you may consider blocking this person and/or reporting abuse
Looks very interesting! I too came from the PHP world and made a 2nd stop at TypeORM (sequelize was my 1st had some really bad experiences with it).
Got one question though, since I see many similarities between TypeORM and MikroORM: Why not try to contribute to the TypeORM community, to help them grow? I think it's OK to reinvent the wheel when learning, but on Open Source wouldn't it make more sense to prefer collaboration with existing solutions instead of rolling out your own? I'd understand if you needed extra power and made a work/proposal that got rejected.
I don't think they are that similar under the hood. TypeORM does not implement neither unit of work nor identity map, so the underlying logic is really different I believe.
My main reason to start new project was not to be bound by such a huge community - I don't see how we could maintain back compatibility while introducing UoW and IM to TypeORM. It would have to be another (optional) way to use it, which would make it even more complex (which it already is).
Sounds fair!
TypeORM code is so complex and was started in a time when js/ts language features were lacking. I think the TypeORM API has some fundamental issue like it uses too much string building for queries.
Hello. This is very nice. May I ask whats the difference between Entity manager and repository? Can I use them interchangeably? Or they work together in the same way? Can I use it like an active record? If there not the same is there a benefit over the other? Thank you for your response sir. Will definitely share this to some friends.
Example:
Ps: i googled the difference, it shows the stack over flow about java and its all abstraction over the other.
All what depository does it to forward the calls to EM, so the only real difference is that it bares the entity name for you. Check the source code, its really just about that:
github.com/mikro-orm/mikro-orm/blo...
So the benefit is that the API is simpler (no need to pass the entity name), and that repositories are an extension point - you can implement your own and add more methods there.
And no, there is no active record support and it never will be - I don't think it could even work.
But still I can use the
EntityManager
like:I'm asking this because instead of importing
em
each time you want to access an Entity would be cumbersome. Instead, I can just extend its static methods.Thank you for the great response sir.
No, as I said, this is not supported. You need to have an instance of entity manager (one per each request) as it holds the state (identity map).
I know you metioned you had mongodb in mind when writing
I've read that sql type of relationships are actually not that useful in mongo and can put some performance penalties on large datasets, are the relationship decorators useful in the case of mongodb?
Sure they are! MikroORM uses simple queries to fetch relationships so that each database table is queried once instead of complex joining. I believe that the problem you are talking about is when using complex aggregations to imitate SQL joins, which is not the case here.
Take a look here for example of how populating relationships work: b4nan.github.io/mikro-orm/nested-p...
One note about performance - there are 4 test suites testing entity manager, one for each driver, and the mongo driver one runs about 2-3x faster than mysql/postgres (sqlite one is of course fastest).
Ahh I overlooked that in the docs! I shall take this one on a spin then :) awesome Project by the way!