Nested relationship filters #272
Conversation
jesstelford
force-pushed
the
nested-relationship-filters
branch
from
cf1d814
to
de09289
Compare
| @@ -140,45 +139,6 @@ describe('Access control package tests', () => { | |||
| expect(() => parseFieldAccess({ access: 10 })).toThrow(Error); | |||
| }); | |||
|
|
|||
| test('mergeWhereClause', () => { | |||
There was a problem hiding this comment.
Shifted these tests (and the associated function) out to @keystonejs/utils because they're not access-control specific, and it's a generic function.
| @@ -272,6 +270,7 @@ module.exports = class List { | |||
| id_in: [ID!] | |||
| id_not_in: [ID!] | |||
| ${queryArgs} | |||
| AND: [${this.gqlNames.whereInputName}] | |||
There was a problem hiding this comment.
This enables the AND query syntax. (see the tests)
| @@ -300,15 +299,18 @@ module.exports = class List { | |||
| return types; | |||
| } | |||
|
|
|||
| getAdminGraphqlQueries() { | |||
| const commonArgs = ` | |||
| getGraphqlFilterFragment() { | |||
There was a problem hiding this comment.
Making this its own function allows the Relationship type to pull in the same input types for nested fields.
|
|
||
| if (many) { | ||
| return `${this.path}( | ||
| ${this.getListByKey(ref).getGraphqlFilterFragment()} |
There was a problem hiding this comment.
This is the nested relationship input type. ie;
author(UserWhereInput): [User]
| ): [${ref}]`; | ||
| } | ||
|
|
||
| return `${this.path}: ${ref}`; |
There was a problem hiding this comment.
to-one relationships can't have any filters, etc, applied.
We can revisit this in the future if we think it's useful to add.
|
|
||
| let server; | ||
|
|
||
| beforeAll(() => { | ||
| server = setupServer({ | ||
| name: 'Tests queries and relationships', | ||
| name: `ks5-testdb-${cuid()}`, |
There was a problem hiding this comment.
I accidentally used the same name in two different test files, and got weird failures until I realised that the dropDatabase command was nuking the DB mid-test from another file (because of the way jest parallelises tests). To protect agains that silly mistake in the future, I've made each test have a unique database name.
| resolveAllKeys( | ||
| afterAll(async () => { | ||
| // clean the db | ||
| await resolveAllKeys(mapKeys(server.keystone.adapters, adapter => adapter.dropDatabase())); |
There was a problem hiding this comment.
This removes that random database name, so your local mongo instance isn't full of cruft.
|
|
||
| test('explicitly filters when given a `where` clause', () => {}); | ||
|
|
||
| test('nested to-single relationships can be filtered within AND clause', async () => { |
There was a problem hiding this comment.
Note that these tests are more robust query tests. They are not nested query tests (see further below for those). Included here as I wanted to cover some more edge cases to be certain I hadn't broken anything.
| id | ||
| posts (where: { | ||
| content_contains: "hi", | ||
| }){ |
There was a problem hiding this comment.
Ooooh, Aaaaahh.
| notes { | ||
| id | ||
| content | ||
| } |
There was a problem hiding this comment.
Access Control means these can't be read (rightfully so).
jesstelford
force-pushed
the
nested-relationship-filters
branch
from
491fa3a
to
1b25dfd
Compare
|
🎉 Will merge once CI passes |
|
Oh god that feels good. |
Fixes #210
You can now do queries like so:
It accepts all the same filtering arguments as a top-level
allPostsquery would 😍I've left comments in line below for your guidance.