spring-projects / spring-data-mongodb

Provides support to increase developer productivity in Java when using MongoDB. Uses familiar Spring concepts such as a template classes for core API usage and lightweight repository style data access.
https://spring.io/projects/spring-data-mongodb/
Apache License 2.0
1.62k stars 1.09k forks source link

Should MappingMongoConverter#read really require to call getCollection of MongoPersistentEntity? #3899

Open xjme opened 2 years ago

xjme commented 2 years ago

Hi, we want to upgrade from spring boot 2.5.x to version 2.6.x. In the new version of SB, the spring data mongo db was updated from version 3.2.x to 3.3.x.

In our code base, we often use MappingMongoConverter provided by MongoTemplate and try to deserialize a document (bson object) to Java entity (using MappingMongoConverter#read(Class<S> clazz, Bson bson)).

In version 3.3 of spring data mongodb, you added method #findContextualEntity, which requires retrieving the collection name from the MongoPersistentEntity.

I think the need to know the name of the collection is too strict and within the simple deserialization of the bson object, this should not happen.

Can you please consider this condition or possibly explain to me why this is needed even within the simple deserialization of any bson object?

To be more clear, I am talking about the implementation of private method with signature private <S> S read(ConversionContext context, MongoPersistentEntity<S> entity, Document bson), which calls the stated findContextualEntity method.

Thanks you for your reconsideration and reply.

petrkalivoda commented 2 years ago

Would it at least be possible to make MappingMongoConverter more extensible? findContextualEntity and private <S> S read(ConversionContext context, MongoPersistentEntity<S> entity, Document bson) are both private and we'd really like to modify this behavior in some non-hackish way.

Steve973 commented 1 year ago

I am using the MongoPersistentEntity and MongoEntityInfo in an attempt to customize repositories to use a collection name that I am setting at configuration time. I need to create a list of repositories, and the number of repositories is dependent on the configuration. So, I have no idea what it's going to be at compile time, and if each repository uses the same model class (and if I don't want to have to mandate the exact collection name) then I need to be able to set the collection at configuration time. The interface repositories (where you don't extend them for a custom implementation) do not obtain the collection names this way. So, I would say that all methods that obtain the collection name should do it in a consistent way in order to ensure predictable behavior. In the way that I'm doing it, it appears to be inconsistent. You can see what I'm doing in this github repository.