Appreciation post about kmongo HOT 10 OPEN

Thank you for the appreciation ! It was a pleasure to develop kmongo all these years :)

The MongoDb team has decided in the end to start from scratch, as they will maintain the driver. It was easier for them (and cleaner for their users) to understand the entire code base. And I agree with this decision.

I still intend to develop a third party library inspired from kmongo, to add some syntactic sugar to the mongo driver. I haven't found the time yet, but I think I will when I start migrating my own projects :)

from kmongo.

I still intend to develop a third party library inspired from kmongo, to add some syntactic sugar to the mongo driver. I haven't found the time yet, but I think I will when I start migrating my own projects :)

Any progress or ETA on this, and is there anything the community could help you with? The official driver feels so much worse to use, and I could spare some time to help write kmongo-style wrappers around it for the convenience and type safety we were used to.

from kmongo.

I have the same view. The official driver is just the java driver trying to pretend they know Kotlin. Yours is actually embracing the power of kotlin and using its features and style.

from kmongo.

My personal opinion is you should continue support this project and undeprecate it and make it like mongoose defeat the official driver

from kmongo.

A few days ago, I tried migrating to the official repository, but it failed. The polymorphic data classes using kotlinx.serialization could not be stored in the database, and the classes of kotlinx-datetime were encoded as strings instead of timestamps by default.

If someone also has similar requirements, migrating may not be a good idea for now.

from kmongo.

and the classes of kotlinx-datetime were encoded as strings instead of timestamps by default.

This might be because kotlinx-datetime defaults the serialisation of Instant to the InstantIso8601Serializer which serialises to a string. I'd actually be confused if that would be different when using KMongo by default - is that really the case?

from kmongo.

and the classes of kotlinx-datetime were encoded as strings instead of timestamps by default.

This might be because kotlinx-datetime defaults the serialisation of Instant to the InstantIso8601Serializer which serialises to a string. I'd actually be confused if that would be different when using KMongo by default - is that really the case?

KMongo serializes kotlinx-datetime correctly by default, at least in my project.

from kmongo.

I still intend to develop a third party library inspired from kmongo, to add some syntactic sugar to the mongo driver. I haven't found the time yet, but I think I will when I start migrating my own projects :)

Any progress or ETA on this, and is there anything the community could help you with? The official driver feels so much worse to use, and I could spare some time to help write kmongo-style wrappers around it for the convenience and type safety we were used to.

Same for me.

from kmongo.

I know the Mongo team is actively working on this type of wrapper. The best option is therefore to wait. I'm very busy on other projects, but I now know that I will have time this summer to work on these wrappers if it proves necessary. For now I upgraded kmongo to Kotlin 2 and Java 5.1 driver

from kmongo.

I, as well, want to thank you for all the work you've done over the years :) MongoDB would definitely not be such a popular option in the Kotlin ecosystem without you.

I still intend to develop a third party library inspired from kmongo, to add some syntactic sugar to the mongo driver.

I have started working on such a project, but it's too soon to be able to show it. Hopefully, I'll be able to publish an MVP in the next ~6 months. I'm focusing on operator safety (avoid confusion between regular operators and aggregation operators that have the same name but different syntax), documentation, and aggregations.

from kmongo.