Allow creating time series collections with custom name and CollectionOptions derived from annotation

[gbaso]

According to the documentation, it is possible to create a time series collection via MongoTemplate by either providing explicit CollectionOptions or a class annotated with @TimeSeries:

@TimeSeries(timeField = "timestamp")
record MyTimeSeries(@Id String id, Instant timestamp, String value) {}

mongoTemplate.createCollection(MyTimeSeries.class)

in which case the CollectionOptions are derived from the annotation: https://github.com/spring-projects/spring-data-mongodb/blob/b8b93bcf93050d923aadef60a8142eda03c8f62f/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/core/EntityOperations.java#L1058-L1081

However, if you want to create the collection with a custom name (not derived from the class), there is currently no option for deriving the CollectionOptions from the annotation. The only overloads of mongoTemplate.createCollection that take a String collectionName also require explicit CollectionOptions.

Using mongoTemplate.save(value, "myCustomName") is a non-starter since it does not read the entity metadata and just creates a basic collection (not a time series) with no other options.

Custom names are important for several widespread use cases, for example collection-level multi-tenancy, where you would create multiple collection with the same definition to segregate data for different tenants, or any other types of data segmentation.

I propose new methods to create a collection that take both the collectionName and the entityClass as inputs:

	public <T> MongoCollection<Document> createCollection(String collectionName, Class<T> entityClass) {
		return createCollection(collectionName, entityClass,
				operations.forType(entityClass).getCollectionOptions());
	}

	public <T> MongoCollection<Document> createCollection(String collectionName, Class<T> entityClass,
			@Nullable CollectionOptions collectionOptions) {
		Assert.notNull(collectionName, "CollectionName must not be null");
		Assert.notNull(entityClass, "EntityClass must not be null");
		return doCreateCollection(collectionName,
				operations.convertToCreateCollectionOptions(collectionOptions, entityClass));
	}

[mp911de]

Let me see whether I understand your request correctly. You're looking for a way to create a timeseries collection that derives its CollectionOptions from a Class but you want to specify a custom name?

If so, then this is not possible. We do not expose our utilities that derive information from annotations for application-code usage. These utilities are private and not part of our public API.

You can call however MongoOperations.createCollection(String collectionName, @Nullable CollectionOptions collectionOptions)

[gbaso]

You're looking for a way to create a timeseries collection that derives its CollectionOptions from a Class but you want to specify a custom name?

Yes, that is correct.

If so, then this is not possible. We do not expose our utilities that derive information from annotations for application-code usage. These utilities are private and not part of our public API.

There is no need to expose those utilities. New overloads for MongoOperations.createCollection would be sufficient.

This is precisely what MongoOperations.createCollection(Class<T> entityClass) already does. Despite the misleading javadoc, it doesn't just derive the collection name from the entity class, it also derives the CollectionOptions, which is very convenient for time series.

[gbaso]

Hello @mp911de, can you take a second look at this? What I'm proposing is

interface MongoOperations {

  <T> MongoCollection<Document> createCollection(Class<T> entityClass, String collectionName);

}

which at the moment is missing. This method would derive the collection options from the entityClass, but use the provided collection name. Implementation would be something like

class MongoTemplate implements MongoOperations {

  @Override
  public <T> MongoCollection<Document> createCollection(Class<T> entityClass, String collectionName) {
    CollectionOptions collectionOptions = operations.forType(entityClass).getCollectionOptions();
    return doCreateCollection(collectionName,
        operations.convertToCreateCollectionOptions(collectionOptions, entityClass));
  }

}

[mp911de]

Looking at the design, we could introduce CollectionOperations (similar to IndexOperations) to create/drop/check for existence and collection lookup. We have several methods interacting on the collection level and adding yet another overload doesn't seem ideal.

[therepanic]

If no one doesn't mind, I can implement this feature.

If so, can you describe how this change could be best implemented architecturally?