Add overload of MongoOperations.stream(…) to take an explicit collection name [DATAMONGO-1431]

[spring-projects-issues]

Vojtech Letal opened DATAMONGO-1431 and commented

Right now I am playing with Spring Data MongoDB and I need to have multiple collections consisting of object of the same class. All of the collections can be possibly large so I can not even use MongoTemplate because MongoTemplate#stream(Query, Class) also does not allow me to specify the collection name. Also it also means that the stream(…) method definition is inconsistent with findAll(…), which has a variant allowing you to specify the collection

---

Affects: 1.9.1 (Hopper SR1)

Issue Links:

• DATAMONGO-252 Provide an Iterator over DBCursor
  ("supersedes")

Referenced from: commits 325bcd1

[spring-projects-issues]

Oliver Drotbohm commented

Are you aware that you can customize the collection an entity is supposed to be stored in via the @Document annotation?

[spring-projects-issues]

Vojtech Letal commented

Yes. But how does it solve my problem of not being able to store instances of the same class into multiple distinct collections in MongoDB?

And even if you argue that my usecase is useless in general, than I still think that at least the erasures of find(...) and stream(...) should be the same

[spring-projects-issues]

Oliver Drotbohm commented

I didn't want to offend anyone. All I was trying to find out is whether you were generally wondering how to alter the collection an entity is mapped to in the persistence layer. That wasn't necessarily clear from the ticket description as the summary mentions repositories and the actual description then discussing the design of MongoOperations.

It might be worth noting that you can use SpEL expressions in the collectionName attribute so that you could refer to another Spring bean from within it and dynamically calculate the collection you want to use for each persistence operation. Some user have used that to lookup a thread-bound discriminator and thus use tenant specific collections, e.g. using @Document(collectionName = "#\{@mySpringBean.determineCollectionForPerson()\}"). That would even allow you to use the stream(…) methods that don't take an explicit collection as you'd just move the definition of the collection name into the method referenced in the SpEL expression, rather than handing it to the MongoOperations instance directly. On the repository level, we don't explicitly expose such parameters as this would basically break the abstraction, as clients would be exposed to the notion of a collection name, which the repository is supposed to prevent.

I definitely see the point of the lacking symmetry in findAll(…) VS. stream(…) and I think we're going to use this ticket to fix that