Skip to content

Add readPreference secondaryPreferred to QueryCursorPreparer #3669

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
peterfouquet0001 opened this issue Jun 15, 2021 · 10 comments
Closed

Add readPreference secondaryPreferred to QueryCursorPreparer #3669

peterfouquet0001 opened this issue Jun 15, 2021 · 10 comments
Labels
status: superseded An issue that has been superseded by another

Comments

@peterfouquet0001
Copy link

Hello,
we will execute find queries on the secondaries in our mongo cluster, but the CursorOption SECONDARY_READS is mapped to primaryPreferred in MongoTemplate.QueryCursorPreparer.getReadPreference. The mapping isn't customizable and the code isn't extendable by subclassing the MongoTemplate.
Please add a mapping for CursorOption SECONDARY_PREFRERRED with secondaryPreferred.
Kind regards
Peter

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 15, 2021
@mp911de
Copy link
Member

mp911de commented Jun 15, 2021

CursorOption is a legacy from the early MongoDB driver where DBCollection.find(…) accepted a flag parameter called option. See the historical Javadoc of QUERYOPTION_*. The modern driver with MongoCollection does not accept options at all, however, the mentioned code is in place for compatibility reasons.

If you want to customize ReadPreference, please set it directly on MongoTemplate

@mp911de mp911de added the status: waiting-for-feedback We need additional information before we can continue label Jun 15, 2021
@peterfouquet0001
Copy link
Author

peterfouquet0001 commented Jun 15, 2021

How can I set a different ReadPreference for a single query?
With the mongo driver i use mongoCollection.withReadPreference(ReadPreference.secondaryPreferred()) to execute these query on a secondary, while all other queries where execute with the defaultReadPreference on the primary.
When I change the read preference for the mongo template, I change the read preference for all queries.
Also i will configure these option for a query with the @meta annotation. Or is there any other way to execute a single query with a different read preference.
{code}
@OverRide
@meta(flags = {SLAVE_OK})
@query("{}")
List findAll();
{code}

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jun 15, 2021
@mp911de
Copy link
Member

mp911de commented Jun 16, 2021

You could override MongoTemplate's MongoCollection<Document> prepareCollection(MongoCollection<Document> collection) to supply a read preference based on the collection. Other than that, there's no method that would accept sufficient context to determine a ReadPreference.

@mp911de mp911de added the for: team-attention An issue we need to discuss as a team to make progress label Jun 16, 2021
@peterfouquet0001
Copy link
Author

peterfouquet0001 commented Jun 16, 2021

When I override the prepareCollection I can't set the read preference for a single query and i can't set the read preference for an annotation based query, because these queries are using the mongo template implizit.
The only way to support query specific read preferences is extending the CursorOptions and the mapping in the QueryCursorPreparer

@mp911de
Copy link
Member

mp911de commented Jun 16, 2021

Let me take your request to our team to check whether we can come up with something. For WriteConcern we have a WriteConcernResolver taking a MongoAction as context parameter.

@peterfouquet0001
Copy link
Author

HI,
do you have a solution to configure the ReadPreference for a single query?
Kind regards
Peter

@mp911de mp911de added the type: enhancement A general enhancement label Jun 28, 2021
@mp911de
Copy link
Member

mp911de commented Jun 29, 2021

Right now, we do not have the means to configure ReadPreference on a per-query basis. Introducing a ReadPreferenceResolver is something that we want to explore in combination with a possibility of declarative configuration that can be used with repository query methods.

@mp911de mp911de removed for: team-attention An issue we need to discuss as a team to make progress status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels Jun 29, 2021
@david-azevedo
Copy link

Hey @mp911de, adding some more info that might be useful here. We have a similar use case where we would like to set the read preference per query (basically we always read from the secondary, but when we don't find anything we then try to read from the primary).
To work around this, we are setting the readPreference on the Template to secondary before reading for the first time and setting it to primary before retrying. After some investigation, we found that for our particular implementation which is multithreaded, this causes race conditions. It would be highly appreciated if it was possible to set the readConcern on a query basis the same way it is possible to do it via mongo shell

@Liveitabhi14
Copy link

And why does the SECONDARY_READS cursor option return a primaryPreferred() ReadPreference?
Shouldn't it return either secondary() or secondaryPreferred() ?

Maybe I am missing something.. can anyone explain

@mp911de
Copy link
Member

mp911de commented Feb 28, 2023

Fixed via #4286.

@mp911de mp911de closed this as not planned Won't fix, can't repro, duplicate, stale Feb 28, 2023
@mp911de mp911de added status: superseded An issue that has been superseded by another and removed type: enhancement A general enhancement labels Feb 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
Development

No branches or pull requests

5 participants