Можно ли связать мутацию graphql внутри класса DataFetcher вместе с запросом? - PullRequest
Новая
       11

Можно ли связать мутацию graphql внутри класса DataFetcher вместе с запросом?

0 голосов
/ 24 июня 2018

Ошибка: FieldUndefined: поле 'createUser' в типе 'Query' не определено @ 'createUser' "

@Service
public class GraphQlService {

    @Value("classpath:schema.graphql")
    Resource resource;

    private GraphQL graphQL;


    @Autowired
    UserDataFetcher userFetcher;
    @Autowired
    PostDataFetcher postFetcher;


    @PostConstruct
    public void loadSchema() throws IOException {

        File schemaFile = resource.getFile();
        TypeDefinitionRegistry typeRegistry = new SchemaParser().parse(schemaFile);
        RuntimeWiring wiring = buildRuntimeWiring();
        GraphQLSchema schema = new SchemaGenerator().makeExecutableSchema(typeRegistry, wiring);
        graphQL = GraphQL.newGraphQL(schema).build();


    }

    private RuntimeWiring buildRuntimeWiring() {
        return RuntimeWiring.newRuntimeWiring()
                .type("Query", typeWiring -> typeWiring
                        .dataFetcher("user", userFetcher)
                        .dataFetcher("post", postFetcher))
                .type("Mutation", typeWiring -> typeWiring
                        .dataFetcher("createUser", userFetcher))
                .build();
    }

    public GraphQL getGraphQL() {
        return graphQL;
    }

}

1. Не могу ли я использовать общий datafetcher / reslover для Query и Mutation как я сделал ниже в одном классе. Он не может найти CreateUser 

@Component
public class UserDataFetcher implements DataFetcher<List<User>> {
@Autowired
UserRepository userRepository;

public User createUser(DataFetchingEnvironment environment) {
    String username = environment.getArgument("username");
    String location= environment.getArgument("location");
    User[] follower = environment.getArgument("followers");
    User[] following = environment.getArgument("following");
    Post[] pos = environment.getArgument("posts");

    User user = new User();
    user.setUsername(username);
    user.setFollowers(follower);
    user.setFollowing(following);
    user.setLocation(location);
    user.setPosts(pos);
    return userRepository.save(user);
}


@Override
public List<User> get(DataFetchingEnvironment environment) {
    return userRepository.findAll();
}
}

// SDL ниже для схемы 

schema {
    query: Query
    mutation: Mutation
}

type User{
    id:ID!
    username:String!
    followers:[User]
    following:[User]
    location:String!
    posts:[Posts]
}

type Post{
    id: ID
    title: String!
    author: User!

}



type Query{
    user: [User]
    post: [Post]
}

type Mutation{
    createUser(username: String!, location: String!,followers: [User],following:[User],posts:[Post]):User

}

2. Является ли схема правильной, поскольку в ней говорится, что пользователь и сообщение не упоминаются как тип ввода. Я попытался InputType для пользователя и сообщения, но не могу заставить его работать. Как следует исправить схему для хранения подписчики и подписчики выглядят как?

1 Ответ

0 голосов
/ 12 июля 2018

1) Нет, каждая реализация DataFetcher может выполнять только одну операцию - это метод get, указанный в интерфейсе.Как фреймворк узнает, что нужно вызвать метод createUser?

2) Нет, схема недопустима.Вы не можете использовать User в качестве типа аргумента (ввода).Вам нужно определить отдельный тип ввода, например, 

input UserInput {
   username:String!
   followers:[ID!]
   following:[ID!]
   location:String!
}

Подумайте, если бы вы могли сделать User ввод, как бы вы предоставили обязательный идентификатор?Что если User реализует интерфейс, поскольку интерфейсы не определены для входных данных?Представьте себе, если User имеет рекурсивный тип поля.В выводе это было бы хорошо (поскольку вы непосредственно управляете уровнем вложенности), но было бы невозможно удовлетворить для типа ввода.

Правила для входов и выходов совершенно разные, поэтому типы должны бытьопределяется отдельно.

Кроме того, в этом примере необязательно ожидаются только ID s для последователей или сопровождаемых, а не полных объектов, поскольку это часто имеет смысл.

...