Extending MongoEntityRepository to enable access to all mongo specific driver methods.

[alko89]

I'm using Nest.js and have been testing out Mokro ORM for use with MongoDB.

It seems that currently the usecase is fairly limited, when considering relying only on native* methods. I did found out that when using mongo the EntityRepository is in fact of type MongoEntityRepository, but unfortunately it only contains the additional aggregate method as compared to the abstract EntityRepository.

I think it would make sense to extend MongoEntityRepository to include the rest of the methods that are available to the Mongo driver, like updateMany, deleteMany, findOneAndUpdate, findOneAndDelete...

Doing so would enable more advance use for Mongo specific driver methods, when MongoEntityRepository is used and possibly also make it easier for others to migrate from other mongo specific ORMs like Mongoose

[B4nan]

Not sure what limitations you see, if you want to access those methods, just get the mongo collection via em.getCollection(), you can work with any mongo collection method you want. Adding the methods you mentioned would only add shortcuts for this, no additional features on top of that = no real benefit in having them. Note that I dont really see a reason to add updateMany/deleteMany - we already have that covered via driver interface, and for findOneAndUpdate we have the new em.upsert.

So I would argue non of this would actually enable anything, it's all just about shortcuts.

[alko89]

em is protected, which makes it not possible to access from the entity object. Also this would kind of beat the purpose of an ORM since it would require populating the entities manually.

I'm confused about you mentioning this would only add shortcuts, do you mean to say all these methods are already used by one of the MikroORM methods? Is there a reference docs where it mentions what MikroORM methods uses on the db driver? For example for mongo nativeUpdate uses updateOne, nativeDelete uses deleteOne and so on?

[B4nan]

em is protected, which makes it not possible to access from the entity object.

You can inject it instead of a repository, or use it inside a custom repository (as it is protected, not private). And let that be aside, it's just TS notation, not runtime limitation, you can always use type assertions to get around that.

But you are right that this em.getCollection() method should be present on the MongoEntityRepository level too, added here so will be available in next dev version.

Also this would kind of beat the purpose of an ORM since it would require populating the entities manually.

The methods you mentioned would only be shortcuts just like the aggregate method you already mentioned - it does not deal with anything ORM specific, it just forwards the call to the driver. I don't see a reason to have more methods than the driver interface already provides for the "ORM part".

For example for mongo nativeUpdate uses updateOne, nativeDelete uses deleteOne and so on?

Nope, nativeUpdate uses updateMany and nativeDelete uses deleteMany, I don't see why would you need the *One methods, how would that be different? Either way, those methods woudn't do anything ORM related, so once again, they would be just shortcuts for the driver methods - they don't change entity state anyhow, neither they interact with unit of work.