Support configuring a default scan consistency.

[aaronjwhiteside]

In our organization it's rare that we require specific scan consistencies per query or even document, typically it's the same across all our documents and even projects. We use REQUEST_PLUS.

It would be nice if we could drive this by a configuration property in application.properties, though I expect Spring Boot to actually contain that logic via CouchbaseDataProperties, but it would be nice if Spring Data Couchbase exposed a way to supply this value without using any @ScanConsistency annotation.

Also I want to point out that right now all the methods inherited in org.springframework.data.couchbase.repository.CouchbaseRepository, from the extended interfaces, currently can ONLY use the default scan consistency of NOT_BOUNDED, with the exception of List<T> findAll(QueryScanConsistency queryScanConsistency); but honestly that method is an outlier.

This means for documents that require REQUEST_PLUS we cannot use any of the stock methods in org.springframework.data.couchbase.repository.CouchbaseRepository, and we end up re-implementing them in a custom repository just so we can annotate them with @ScanConsistency.

[aaronjwhiteside]

One possible step in the right direction to help with this problem would be to allow @ScanConsistency on the repository class level. Placing @ScanConsistency on a custom query method would allow overriding of this repository default.

Though it wouldn't allow us to drive this via configuration ala application.properties it would allow for a sane workaround.

Obviously the code in SimpleCouchbaseRepository would need to be modified to take this annotation into account, so that ALL the repositories methods would honor it.

[mikereiche]

The plan is to add Type as a target of the @ScanConsistency annotation, and handle it in the same places as the method-level annotation is handled.

[aaronjwhiteside]

Sounds good to me.

Would this continue to work if placed on some super interface?

@NoRepositoryBean
@ScanConsistency(query = QueryScanConsistency.REQUEST_PLUS)
public interface BaseRepository extends CouchbaseRepository {}

@Repository
public interface MyRepository extends BaseRepository {}

[mikereiche]

It's possible to check for annotations on the interfaces implemented by the class. Like this (should probably do this recursively and take the one "closest" to the method) (Originally said something different)

	Class clazz = method.getDeclaringClass();
	if( clazz.getAnnotation(ScanConsistency.class)!= null) {
		ScanConsistency sc = (ScanConsistency) clazz.getAnnotation(ScanConsistency.class);
		System.out.println("QSC: " + sc.query());
		Class<?>[] interfaces = clazz.getInterfaces();
		for (Class<?> ifc : interfaces)
			if (ifc != null && ifc.getAnnotation(ScanConsistency.class) != null) {
				ScanConsistency ssc = (ScanConsistency) ifc.getAnnotation(ScanConsistency.class);
				System.out.println("QSC: " + ssc.query());
			}
	}

[aaronjwhiteside]

Most restrictive might cause issues?

I can imagine cases where I might want to declare consistency as REQUEST_PLUS in a base interface, but override it to be NOT_BOUNDED in a sub interface for some specific operation that doesn't require it.

@NoRepositoryBean
@ScanConsistency(query = QueryScanConsistency.REQUEST_PLUS)
public interface BaseRepository extends CouchbaseRepository {}

@Repository
public interface MyRepository extends BaseRepository {
    @ScanConsistency(query = QueryScanConsistency.NOT_BOUNDED)
    List<My> someQuery();
}

So the heuristic should be something like this,

1. Is method annotated with @ScanConsistency
2. Is class annotated with @ScanConsistency
3. Is method overriding another? Is super annotated with @ScanConsistency
4. Does the class inherit? Is the parent annotated with @ScanConsistency
5. For interfaces, order of extends matters, A extends B, C If B and C both contain class level annotations then B wins. If both B and C contain the same method definition and they are both annotated with @ScanConsistency, B wins.
6. Recurse over the super classes.

I haven't looked to closely, but:
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/annotation/AnnotationUtils.html
and or https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/annotation/MergedAnnotations.html might be helpful here

[mp911de]

FWIW, we have similar functionality in Spring Data JPA regarding query hints on the method level. Obtaining the annotation for query methods is simple as the infrastructure can get hold of the actual Method. For implementation methods (Simple…Repository) this requires an additional interceptor to store the annotation details in a ThreadLocal so that the repository implementation can get hold of the annotation data.

[mikereiche]

This should be supported on repositories with #1149 Scopes and Collections which is in 4.3.0 milestone 2.
The spring-provided annotation utilities are used to choose among multiple annotations.