The subject is an error that happens technically inside the mongo-java-driver not kmongo. However, what I believe will be of immense help to everyone (given the amount of times this question is asked and the answer is there is no answer), I believe kmongo can provide a nice clean solution to the problem at hand with its extensions.
The reason the above error happens apparently has to do with the "order" that data is stored in mongo. So for example if you have a collection called Tenant with data as
{ "_id" : 42, "url" : "somewhere.com", "updated" : ISODate("2016-07-29T14:32:55.123Z"), "title" : "United States Post Office" }
And if you have a data class like
data class Tenant(@MongoId val id: Int, val title: String?)
There is a conflict because after the _id it is expecting a title not a url as is the case above. If the data is actually stored as _id first and title second then everything works as expected.
As I said the above is a mongo error. However, what would be extremely helpful is to allow a work around or fallback. Since there are already reified helper for kotlin support, the reified helper can actually wrap the real getCollection method with a try/catch for this specific error and in this scenario and create the bean instead using the normal extendedJsonMapper on the original document format of that record.
Or if that is just too complicated, just have an extentions hook like
MongoDatabase.getCollectionAs() which would effectively do a normal getCollection call without providing it the auto-transformation, grab the resulting data as the raw mongo document, and then doing an extendedJsonMapper on that results data.json to cast it using the normal JsonSerializer instead of the BsonSerializer (at least until the year+ long bug has been resolved).
Not sure if any of this made sense but ideally it might be something like
val collection = mongodb.getCollectionAs().find()
does the same thing as
val collection = mongodb.getCollection().find()
except that its underlying implementation is to use the extendedJsonMapper instead of letting native mongo use the BsonMapper (which is not supportive of data being in different order). In theory it is slower and uses more memory (have to serialize/deserialize everything instead of only deserializing) but in a rough POC (having to do this same sort of thing to work around the bug now), I'm seeing no actual difference in performance for large sets of data.