Improve how Querydsl and Query by Example auto registration fits in the hierarchy of DataFetcher registrations

[dugenkui03]

I think the goal of AutoRegistrationTypeVisitor#hasDataFetcher is that: determine whether the field bind customized DataFetcher, instead of default DataFetcher.

spring-graphql/spring-graphql/src/main/java/org/springframework/graphql/data/query/AutoRegistrationTypeVisitor.java

Line 104 in a15fd29

return (fetcher != null && !(fetcher instanceof PropertyDataFetcher));

But user can change the default DataFetcher of GraphQL Java by GraphQLCodeRegistry#defaultDataFetcherFactory. It will be more accurate to replace PropertyDataFetcher to DefaultDataFetcher.

[rstoyanchev]

What is DefaultDataFetcher? I don't find such a type.

Keep in mind, we expect DataFetcher registrations to be made via RuntimeWiringConfigurer and likewise GraphQlSource.Builder supports a default TypeResolver registration, so I'd expect there to be no reason to set GraphQLCodeRegistry.

[dugenkui03]

Maybe I haven't make things clear. default DataFetcher is not a concrete Java Class: If schema field not register DataFetcher manully, the GraphQL Java will register default DataFetcher for this field.

Details in code sample, and I think change like that will avoid this error:

	private boolean hasDataFetcher(
			GraphQLCodeRegistry.Builder registry, GraphQLFieldsContainer parent,
			GraphQLFieldDefinition fieldDefinition) {

		DataFetcher<?> defaultDataFetcher = registry.getDefaultDataFetcherFactory().get(null);

		DataFetcher<?> fieldFetcher = registry.getDataFetcher(parent, fieldDefinition);
		return (fieldFetcher != null && !(defaultDataFetcher.getClass().isInstance(fieldFetcher)));
	}

[rstoyanchev]

Thanks for clarifying.

We've already run into some challenges with the way auto-registration works, related to extended validation (see #240). I'm going to experiment with replacing the AutoRegistrationTypeVisitor with a RuntimeWiringConfigurer that sets a defaultDataFetcherForType for each type that it needs to auto-register. This allows an application to override it through a regular registration but will also take precedence over a defaultDataFetcher as you have shown.