Enhance MongoRepository interface to support findAndModify methods of Mongo Db [DATAMONGO-1613]

[spring-projects-issues]

Kollivakkam Raghavan opened DATAMONGO-1613 and commented

In many instances (e.g. managing state of an object in multi-threaded applications), it is necessary to make atomic updates to a document. MongoDBs findAndUpdate methods are designed to allow exactly this use case. While MongoTemplate has these methods, they are not exposed through the MongoRepository interface.

This enhancement request is to expose these methods via the repository interface.

(I have gotten around this for the moment by extending SimpleMongoRepository and the MongoRepository interface and using a custom factory. I can easily add this to the core classes and submit a pull request if that is acceptable)

---

Affects: 1.9.7 (Hopper SR7)

1 votes, 3 watchers

[spring-projects-issues]

Micheal Swiggs commented

Is there an example of using a custom factory to implement this?

[spring-projects-issues]

Oliver Drotbohm commented

As you'd need more fine-grained control over the way you use the MongoDB APIs for that there's hardly any point in pulling this up into the repository API as that would leak implementation details into repository clients. The repository is exactly the place to encapsulate that kind of logic.

Custom repository extensions can easily be written. How to achieve that is documented here

[spring-projects-issues]

Oliver Drotbohm commented

Closing as won't fix for the reasons described in my previous comment

[spring-projects-issues]

Kollivakkam Raghavan commented

-The findAndModify methods are specific to and core to the Mongo APIs.  As such adding it to the MongoOperations interface doesn't seem like such a big stretch to me.  It doesn't violate any of the core spring data contracts or design patterns.  People who use MongoDb and spring-data-mongodb will use MongoOperations and MongoRepository based interfaces anyway.  It seems silly to need to extend MongoRepository and create a MongoTemplate wrapper just to accomplish this.  The wrapper we have merely forwards the findAndModify exposed from the subinterface to the mongo templates method.   Unlike relational databases, for Mongo Db to leverage their aggregation pipeline.  Once you do that you are locked in to the DB.  If you don't leverage the aggregation pipeline (which gives you some measure of portability) you're really not even using a small fraction of what Mongo can do for you.  For what it's worth I disagree with the comment on leaking.-

[spring-projects-issues]

Oliver Drotbohm commented

I think you misunderstood and a lot of stuff you mention wasn't even implied in the first place. The ticket is about adding APIs to the repository, not MongoOperations. The latter already exposes those operations. So it's very natural to just write the code that uses the operations and hide them inside the repository so that client code is not aware of how the repository operation is executed, whether that's a MongoDB aggregation or a fancy SQL statement. That's application specific code, not a direct 1:1 lift of a MongoOperations method into the repository.

Simply forwarding the calls within a repository is wrong as it lowers the abstraction level of the repository and forces clients to work with Update etc. The repository is supposed to expose a more high level API that's than translated into the appropriate combination of queries and updates within the repository

[spring-projects-issues]

Kollivakkam Raghavan commented

Sorry - you are correct - my explanation wasn't very crisp.  I'll clarify here (please ignore my last comment) - I had to extend MongoOperations for a very different reason and I mixed the two things up.  I've kept my comments and crossed them out so it'll make sense for historical reasons.

• Create a repository interface that extends MongoRepository to expose these methods (in our case this is ok since we're pretty locked in to MongoDb)
• Extend SimpleMongoRepository that wrapped the findAndModify methods and just delegated them to the template.
• Use this extended base class as my repositoryBaseClass 

My point was that since we're only extending MongoRepository and not the base Spring data repository methods and since findAndModify is a core part of MongoRepositories, what is the harm in exposing those additional methods in that repository.

I'm not completely following the last paragraph but that is probably a reflection of a lack of deeper understanding of the design/architecture.

Thx for your response.  The workaround I have is not very painful - my enhancement request was more a question of whether it made sense to include it in the MongoRepository or not.  There are enough hooks for me to accomplish what I need so I I'll retract my statement from the previous comment