Closed Typraeurion closed 4 months ago
execute(Class<?> entityClass, CollectionCallback<T> callback)
merely derives the collection name from a given type. While this can be useful for cases where the collection name is dynamic (e.g. by using SpEL expressions), we should rather capture the collection name that was given during index operations creations. The reactive counterpart of index operations sticks already to the given collection name.
That being said, I consider this behavior a bug.
I have an object type that is stored in MongoDB under two tables: one using the default (class) table name, another using a custom name. The code needs to ensure a geospatial index exists on the table before doing a “near” query. It looks something like this:
When executing the query, it fails with:
and checking the tables in mongosh I found the index was created on the “place” table, not on “topPlaces”. I traced the fault down to this line in
DefaultIndexOperations.execute(callback)
:https://github.com/spring-projects/spring-data-mongodb/blob/7821c2a545da5ac10529f0158639e998dfb0072a/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/core/DefaultIndexOperations.java#L212
which prioritizes executing the callback for the
type
of the collection if present over thecollectionName
.If this is the intended behavior of
indexOps(collectionName, type)
, it’s not documented. The javadoc implies that thetype
parameter is only used for field mapping. It also says thatcollectionName
is required, even though it isn’t used.(Caveat: I’m currently running with spring-data-mongodb 4.0.12, but it appears this
execute
method has not been changed in the latest code here on GitHub.)