Skip to content

Using schema name that doesn't exist in OAI spec when calling query #127

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dhmlau opened this issue Mar 12, 2019 · 7 comments
Closed

Using schema name that doesn't exist in OAI spec when calling query #127

dhmlau opened this issue Mar 12, 2019 · 7 comments

Comments

@dhmlau
Copy link
Member

dhmlau commented Mar 12, 2019

Describe the bug

After creating a ToDo application using LoopBack, here is the OpenAPI spec:
openapi.txt

In the GraphQL explorer, the correct query is

query {
  todos2 {
    title
    desc
  }
}

instead of

query {
  todos {
    title
    desc
  }
}

I'm wondering where is the todos2 is coming from? It doesn't seem to be matching the schema name or the endpoints.

@dhmlau
Copy link
Member Author

dhmlau commented Mar 12, 2019

IIRC, at some point, I was using todos because we verified our instructions in the Quick Lab here: https://developer.ibm.com/tutorials/create-rest-apis-minutes-with-loopback-4/.

@ErikWittern
Copy link
Collaborator

@dhmlau The behavior is expected. OASGraph attempts to base field names on the return types of operations. Because, in your OAS, multiple operations return the Todo type, OASGraph appends numbers to differentiate the fields.

If you want more control, consider using the operationIdFieldNames option (see https://github.com/strongloop/oasgraph/tree/master/packages/oasgraph-cli#usage). If set to true, the operationId defined in an OAS operation is used to name that field. This gives developers more fine-grained control over how the GraphQL interface will look like.

@Alan-Cha
Copy link
Collaborator

Alan-Cha commented Mar 13, 2019

@ErikWittern I took a very brief look at this yesterday and if I recall correctly the todos2 field does not return a Todos2 object but rather an array of Todo objects. The todos field name is also not being used. I have some ideas of what may be going on and I’ll try report back later today.

However, if you cannot wait, @dhmlau, please consider using the operationIdFieldNames option as @ErikWittern has suggested. It should be an easy fix to field name problems.

@Alan-Cha
Copy link
Collaborator

I took a look at @ErikWittern, you are correct. I wasn't sure if arrays had a different mechanism of creating a field name than objects so I went back to check and it turned out to be same. So just to reiterate, this behavior is expected and it is because multiple operations return a type that share the same type name (which is used for the query field names).

We could try to make it so that OASGraph tries to give nice looking type names to GET operations (in this case PATCH /todos received the Todos field name) but this will require a lot of restructuring and naming will always be semi-arbitrary.

For now, please consider using the operationIdFieldNames to manually define field names. Hope this helps!

@dhmlau
Copy link
Member Author

dhmlau commented Mar 14, 2019

@Alan-Cha @ErikWittern , thanks for looking into this. I think my main concern is that the field name has changed from todo at some point to todo2, and it's not about nicer name. If it's the expected behavior, we'll update our docs accordingly. Thanks for the confirmation.

@Alan-Cha
Copy link
Collaborator

@dhmlau Ah, if this is about consistency, then I do not think this issue is resolved. Many seemingly extraneous factors can affect the resulting GraphQL interface. We are looking into this issue with #120. I would hold off on updating the docs for now and I will try to resolve this as soon as possible.

@Alan-Cha Alan-Cha reopened this Mar 14, 2019
@Alan-Cha
Copy link
Collaborator

Alan-Cha commented May 8, 2019

@dhmlau I believe things should be consistent now with #138. Could you make sure that the docs look correct? Sorry about the long delay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants