You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some applications it's required to change the readPreference for one or more repository (and keep it distinct from a default ReadPreference set on MongoTemplate).
A mechanism similar to WriteConcernResolver would make this very flexible and achieve this functionality.
Currently there are two workarounds which are not very clean:
Creating repository in question with a different MongoTemplate (does not allow per-action preferences changes)
Subclassing MongoTemplate and hooking in desired functionality there
Affects: 1.5 GA (Dijkstra)
The text was updated successfully, but these errors were encountered:
After doing a quick subclassing (workaround #2) myself I realised that it would be great if it's possible to do resolution based on the action performed, not only per collection (as currently allowed by prepareCollection method.
Reason for this addition would be that some operations may need to be done with a different ReadPreference. It's very simple with Mongo Java Driver but MongoTemplate hides this functionality and thus enforces you to either go directly to driver or always use one ReadPreference for all operations (even if it's resolved by Collection, as long as we are not taking Query/Method into consideration).
Unfortunately as pointed out by Oliver, MongoAction is not applicable to find queries and therefore this would be harder to provide such flexibility.
Maybe Repository methods could be annotated with ReadPreference or a class similar to MongoAction (e.g MongoFind) could be added, at least in future iterations of this feature?
Alexej Kubarev opened DATAMONGO-947 and commented
In some applications it's required to change the readPreference for one or more repository (and keep it distinct from a default ReadPreference set on MongoTemplate).
A mechanism similar to WriteConcernResolver would make this very flexible and achieve this functionality.
Currently there are two workarounds which are not very clean:
Affects: 1.5 GA (Dijkstra)
The text was updated successfully, but these errors were encountered: