Skip to content
This repository was archived by the owner on Apr 14, 2022. It is now read-only.

Connection cannot be named as destination collection in some cases #104

Closed
Totktonada opened this issue Apr 1, 2018 · 1 comment · Fixed by #204
Closed

Connection cannot be named as destination collection in some cases #104

Totktonada opened this issue Apr 1, 2018 · 1 comment · Fixed by #204
Labels
bug Something isn't working
Milestone

Comments

@Totktonada
Copy link
Member

The example is user_to_passport_c (the _c postfix is mandatory) in the nesting-3-100-100-1.test.lua benchmark. It seems that we cannot avoid it while fetching type information in the executor by type name (I don’t sure, though) and we need to introduce namespaces.

@Totktonada Totktonada added the bug Something isn't working label Apr 1, 2018
@Totktonada Totktonada added this to the 0.0.1 milestone Apr 17, 2018
@Totktonada
Copy link
Member Author

Related: #70.

@Totktonada Totktonada modified the milestones: 0.0.1, 0.0.2 Jul 10, 2018
SudoBobo added a commit that referenced this issue Aug 9, 2018
Before we could not use the same name for collection and
1:1 connection (or collection and 1:1 multi-head connection
variant) because this created two different types with same
names in GraphQL schema: Object type for collection and
InputObject type for connection. Now we can use the same names,
since we add 'result_' to the name of GraphQL collection
Object type.

Close #191, close #104
SudoBobo added a commit that referenced this issue Aug 10, 2018
Before we could not use the same name for collection and
1:1 connection (or collection and 1:1 multi-head connection
variant) because this created two different types with same
names in GraphQL schema: Object type for collection and
InputObject type for connection. Now we can use the same names,
since we add 'result_' to the name of GraphQL collection
Object type.

Close #191, close #104
SudoBobo added a commit that referenced this issue Aug 10, 2018
Before we could not use the same name for collection and
1:1 connection (or collection and 1:1 multi-head connection
variant) because this created two different types with same
names in GraphQL schema: Object type for collection and
InputObject type for connection. Now we can use the same names,
since we add 'result_' to the name of GraphQL collection
Object type.

Close #191, close #104
Totktonada added a commit that referenced this issue Sep 4, 2018
* fix format_process function
* print whole reject file when test failed (#102)
* print reproduce file when test failed at -j -1 mode (#104)
* print reproduce file content in parallel mode (#104)
* allow to pass arguments to create_cluster
* allow grep_log to not reset search results after tarantool restart
* support comments in config files
* don't kill default if non-default crash expected (#109)
* don't inherit unneeded file descriptors (#117)
* list task for hung workers (#107)
* add new config param 'show_reproduce_content' (#113)
Totktonada added a commit that referenced this issue Sep 4, 2018
* fix format_process function
* print whole reject file when test failed (#102)
* print reproduce file when test failed at -j -1 mode (#104)
* print reproduce file content in parallel mode (#104)
* allow to pass arguments to create_cluster
* allow grep_log to not reset search results after tarantool restart
* support comments in config files
* don't kill default if non-default crash expected (#109)
* don't inherit unneeded file descriptors (#117)
* list task for hung workers (#107)
* add new config param 'show_reproduce_content' (#113)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant