Open ryszardmakuch opened 6 months ago
Thank you for getting in touch. I think we need to work on the documentation side of things here allowSecondaryReads
will use the primary if available but allows secondary nodes to be used if not.
Please use Query#withReadPreference
to set any ReadPreference
directly.
@christophstrobl, thanks for the explanation. Updating the documentation would be useful.
@christophstrobl Wouldn't it make sense to ease the access to this setting by providing a way to define the secondary preference as part of the repository method convention:
@Aggregation(pipeline = {
{ $match: { someDate: { $gte: ?0, $lt: ?1 } } },
{...},
{...}
})
List<SomeEntity> retrieveStatistics
Having to just add the meta flag appears so nice, unfortunately completely not the meaning we expected :) Especially for projects that completely use only high level repository methods, it is cumbersome to have to extract into separate repos and utilizing lower level things just to specify this flag.
So I am not only after more clear documentation, rather after keeping the easy setting
@hadjiski did you have a look at @ReadPreference
which is available since 4.2.
did you have a look at
@ReadPreference
which is available since 4.2.
I must have missed this nice annotation, thanks a lot, it works, even a shortcut is available as part of the aggregation one @Aggregation(readPreference = "secondaryPreferred", pipeline = { ... }
Expected behavior: When I add the
SECONDARY_READS
meta flag using the annotation@Meta(flags = { SECONDARY_READS })
or when.allowSecondaryReads()
is invoked on a query, the read preference should be set assecondary
orsecondaryPreferred
.Actual behaviour: When I add the
SECONDARY_READS
meta flag using the annotation@Meta(flags = { SECONDARY_READS })
or when.allowSecondaryReads()
is invoked on a query, the read preference is instead set asprimaryPreferred
.Is this the intended behavior?
Root cause:
The unit test to reproduce the potential bug discovered: