Support generic operator for relationship filters #5873
Conversation
…s against null values
…ypher-relationship-quantifier
🦋 Changeset detectedLatest commit: f91dd3e The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
…press/graphql into cypher-relationship-quantifier
angrykoala
changed the title
| } | ||
|
|
||
| return fields; | ||
| } | ||
| // Relationship filters |
There was a problem hiding this comment.
Maybe explicitly say non-connection relationship or simple relationship
|
|
||
| // NOTE: This used to be a specialized function used specifically to generate relationship fields, | ||
| // but now after this refactor, it could be used as schema composer utility if needed. | ||
| function fieldConfigsToFieldConfigMap({ |
There was a problem hiding this comment.
For consistency, maybe move the utility function under the exported function?
| function getRelationshipConnectionFiltersLegacy( | ||
| relationshipAdapter: RelationshipAdapter | RelationshipDeclarationAdapter | ||
| ): FieldConfig[] { | ||
| return [ |
There was a problem hiding this comment.
These should be deprecated right? Is this a good place to add that deprecation maybe?
| operator, | ||
| relationship, | ||
| }); | ||
| } | ||
|
|
||
| // TODO: we keep call this Generic filters but maybe we should rename it to something more meaningful | ||
| // Proposal: TypeSpecificFilters |
There was a problem hiding this comment.
🤔
parseGenericTypeFilters?
I'm not sure what TypeSpecific means
| if (objectEntries.length !== 1) { | ||
| throw new Error("Expected one quantifier in a relationship predicate"); | ||
| } | ||
| const [genericOperator, genericValue] = objectEntries[0] as [string, any]; |
There was a problem hiding this comment.
I'm not sure genericOperator is a very good naming convention
We've fallen to that convention for the schema generation types, but here is a bit weird tbh. We are parsing an operator after all. Same with value
| query($movieIds: [ID!]!) { | ||
| ${Movie.plural}(where: { AND: [{ id: { in: $movieIds }}, { actors_${predicate}: { NOT: { flag: {equals: false }} } }] }) { | ||
| ${Movie.plural}(where: { AND: [{ id: { in: $movieIds }}, { actors: { ${predicate}: { NOT: { flag: {equals: false }}} } }] }) { |
There was a problem hiding this comment.
This is going to cause conflicts all over the place
| ${Movie.plural}(where: { AND: [{ id: { in: $movieIds }}, { actors: { ${predicate}: { NOT: { flag: {equals: false }}} } }] }) { | |
| ${Movie.plural}(where: { AND: [{ id: { in: $movieIds }}, { actors: { ${predicate}: { NOT: { flag: {eq: false }}} } }] }) { |
This PR adds the implementation for the generic filtering for relationships such as
actors: { some: { name: { eq: "Keanu Revees" } } } }, it also removes from the 7.x branch the usage ofisNot.