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.

[rstoyanchev]

This ended up a little different, in two changes. The first enables the ability to add any number of WiringFactory instances through an additional configure method on RuntimeWiringConfigurer. The second switches auto-registrating to use a WiringFactory instead of a TypeVisitor.

Note that we'll need a small follow-up change in the Boot starter before this works out of the box. So if you want to try it, please hold off until the Boot change is in place. I'll update here.

[rstoyanchev]

@dugenkui03 the changes in the Boot starter are now also ready, if you'd like to give it a try with 1.0.0-SNAPSHOT and Boot 2.7.0-SNAPSHOT for the starter.

[dugenkui03]

Thanks, the bad logic is still exist in AutoRegistrationTypeVisitor, and I make a pr for this #302.