Skip to content

optimize directive checks in driver #128

Open
@keski

Description

@keski

This ticket is about optimizing the directives check in the driver, which currently suffers from a severe degradation of performance in relation to the number of mutation operations performed in a single mutation, as well as the size of the collections being checked.

For every mutation operation (nested or otherwise) directives checks need to be performed on the object/edge being manipulated and/or related objects. However, depending on the type of operation, we can limit directive checks to a subset of the available directives. All directive checks need to be added with references to the specific objects in question. Since subsequent operations may further modify the database, all checks must also check if the objects in question still exist as part of the validation.

The list below describes the checks that need to be made when manipulating an object/edge affecting fields annotated with a directive. For each type of mutation the directives that need to be checked differ:

  • add object
    • distinct: yes
    • required: yes
    • requiredForTarget: no
    • uniqueForTarget: yes
    • noloops: no
  • add edge (with respect to fields in source/target types)
    • distinct: yes (with respect to field on source)
    • required: no
    • requiredForTarget: no
    • uniqueForTarget: yes (with respect field on target)
    • noloops: yes (with respect to field on source)
  • update object/edge
    • no checks needed since edges are not manipulated
  • delete object
    • distinct: no
    • required: yes (with respect to any object with a required field pointing to source)
    • requiredForTarget: yes (with respect to field on target)
    • uniqeForTarget: no
    • noloops: no
  • delete edge
    • distinct: no
    • required: yes (with respect to field on source)
    • requiredForTarget: yes (with respect to field on target)
    • uniqeForTarget: no
    • noloops: no

Note that the graphql-api-generator adds the @required directive to any reverse edge of a @requiredForTarget field. This means that checking for @requiredForTarget is equivalent to checking the @required directive on the reverse field of the target object.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions