Skip to content
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

Schema View: 2 views with the same interface override each other #2182

Closed
islamaliev opened this issue Jan 10, 2024 · 4 comments · Fixed by #2185
Closed

Schema View: 2 views with the same interface override each other #2182

islamaliev opened this issue Jan 10, 2024 · 4 comments · Fixed by #2185
Assignees
Labels
area/query Related to the query component area/schema Related to the schema system bug Something isn't working
Milestone

Comments

@islamaliev
Copy link
Contributor

islamaliev commented Jan 10, 2024

When creating 2 view that have interfaces with the same name, then one overrides another and the overridden one is not available in the first view anymore.

func TestView_Override(t *testing.T) {
	test := testUtils.TestCase{
		Description: "One to many view with alias on outer object",
		Actions: []any{
			testUtils.SchemaUpdate{
				Schema: `
					type Author {
						name: String
						books: [Book]
					}
					type Book {
						name: String
						author: Author
					}
				`,
			},
			testUtils.CreateView{
				Query: `
					Author {
						name
						books {
							name
						}
					}
				`,
				SDL: `
					type AuthorView {
						name: String
						books: [BookView]
					}
					interface BookView {
						name: String
					}
				`,
			},
			testUtils.CreateView{
				Query: `
					Author {
						authorName: name
						books {
							bookName: name
						}
					}
				`,
				SDL: `
					type AuthorAliasView {
						authorName: String
						books: [BookView]
					}
					interface BookView {
						bookName: String
					}
				`,
			},
			// bae-ef9cd756-08e1-5f23-abeb-7b3e6351a68d
			testUtils.CreateDoc{
				CollectionID: 0,
				Doc: `{
					"name":	"Harper Lee"
				}`,
			},
			testUtils.CreateDoc{
				CollectionID: 1,
				Doc: `{
					"name":	"To Kill a Mockingbird",
					"author_id": "bae-ef9cd756-08e1-5f23-abeb-7b3e6351a68d"
				}`,
			},
			testUtils.Request{
				Request: `query {
							AuthorAliasView {
								authorName
								books {
									bookName
								}
							}
						}`,
				Results: []map[string]any{
					{
						"authorName": "Harper Lee",
						"books": []map[string]any{
							{
								"bookName": "To Kill a Mockingbird",
							},
						},
					},
				},
			},
			// This action results in error: Cannot query field "name" on type "BookView".
			/*testUtils.Request{
				Request: `query {
							AuthorView {
								name
								books {
									name
								}
							}
						}`,
				Results: []map[string]any{
					{
						"name": "Harper Lee",
						"books": []map[string]any{
							{
								"name": "To Kill a Mockingbird",
							},
						},
					},
				},
			},*/
			// This action returns books with "name" field although "bookName" is requested
			testUtils.Request{
				Request: `query {
							AuthorView {
								name
								books {
									bookName
								}
							}
						}`,
				Results: []map[string]any{
					{
						"name": "Harper Lee",
						"books": []map[string]any{
							{
								"bookName": "To Kill a Mockingbird",
							},
						},
					},
				},
			},
		},
	}

	testUtils.ExecuteTestCase(t, test)
}

This issue in this example is minor in my opinion but it seems like there might be more severe implications.

EDIT: After this creation of other views is broken:

			// This action returns error: no type found for given name. Type: BookView.
			testUtils.CreateView{
				Query: `
					Author {
						name
					}
				`,
				SDL: `
					type AuthorDummyView {
						name: String
					}
				`,
			},
@islamaliev islamaliev added bug Something isn't working area/query Related to the query component area/schema Related to the schema system labels Jan 10, 2024
@AndrewSisley
Copy link
Contributor

Nice catch Islam! Will look into this one shortly, I'm also worried that adding an interface with a name of an existing collection might result in similar issues as it looks like the schema is not checking for existing schema of that name before writing to store.

@AndrewSisley
Copy link
Contributor

AndrewSisley commented Jan 10, 2024

After this creation of other views is broken

This is strange, it might be there is a weakness in the descriptions-gql code that permits an in-memory corruption of state. Might be worth looking into how this works later.

It might not just affect new Views, but also new collection/schema.

@AndrewSisley AndrewSisley self-assigned this Jan 10, 2024
@AndrewSisley AndrewSisley added this to the DefraDB v0.9 milestone Jan 10, 2024
@AndrewSisley
Copy link
Contributor

After this creation of other views is broken

This is a separate issue, unrelated to the overwriting problem. I've opened up #2184

AndrewSisley added a commit that referenced this issue Jan 10, 2024
## Relevant issue(s)

Resolves #2184 #2182

## Description

Retain embedded schema within gql types on reload and further GQL
modification.

Also refactors the code a little to make it harder to re-introduce
(calling `loadSchema` instead of sometimes relying on function vars).
@fredcarle
Copy link
Collaborator

closed by #2185 2185

shahzadlone pushed a commit to shahzadlone/defradb that referenced this issue Jan 22, 2024
…ork#2185)

## Relevant issue(s)

Resolves sourcenetwork#2184 sourcenetwork#2182

## Description

Retain embedded schema within gql types on reload and further GQL
modification.

Also refactors the code a little to make it harder to re-introduce
(calling `loadSchema` instead of sometimes relying on function vars).
shahzadlone pushed a commit to shahzadlone/defradb that referenced this issue Feb 23, 2024
…ork#2185)

## Relevant issue(s)

Resolves sourcenetwork#2184 sourcenetwork#2182

## Description

Retain embedded schema within gql types on reload and further GQL
modification.

Also refactors the code a little to make it harder to re-introduce
(calling `loadSchema` instead of sometimes relying on function vars).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/query Related to the query component area/schema Related to the schema system bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants