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).
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!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.