Custom id in collection

[SimoneLazzaris]

Now document collection works with an index field which has to be autogenerated.
In other workds, idFieldName has to always be autogenerated.

As an enhancement, we should support also custom fields to work as primary index.

[prog8]

@SimoneLazzaris are you sure what's needed is a custom field that should be used as a document ID or maybe it's worth keeping the only allowed primary key field as _id? In such an approach instead of requiring _id to be autogereated in each case it can be just taken from the parameters if provided by the user? That's exactly what happens for example in Elasticsearch. Each document has a unique _id field. In case a document contains a field which you know identifies your documents uniquely (for example user ID in users database) you can simply send a document where _id contains a user ID. In such a case documentIdFieldName wouldn't be needed at all. The only thing with this approach is that a given value (here it can be userId) can be duplicated in both _id and userId. I think this is not a big overhead especially for documents which contain many fields.

Maybe there is a use case where this indeed makes sense to point collection to a custom id field instead of _id. @SimoneLazzaris do you have something specific in mind?

[SimoneLazzaris]

I don't have any strong preference, we could totally go the way elasticsearch handle the issue and have the _id field always holding the primary document ID. My point is only that the current system is confusing, since it allows for custom ID names but it doesn't allow the user to provide the content of that field.

Since we already have the option to set documentIdFieldName while creating the collection, I think it will be best (for backward compatibility) to just allow the user to set the content of the ID field while loading documents. But again, no strong preference.