Preliminary checklist

• I understand that all communication must be in English
• I read the Documentation
• I read the Contributing guide
• I agree to follow the Code of Conduct
• I searched the issues and discussions but couldn't find anything (or linked relevant results below)

Problem

Right now there's no way to actually create, read, update and delete relationships for existing entities.

Solution

The solution for this issue is implementing new dynamic queries and mutations based on the database structure. Depending on the relationship type different solutions are provided.

Progress

• One to one
• One to many
• Many to one
• Many to many

One to one

Example: on this example there's an entity being Department, and another being Manager, and a relationship one to one between those two entities called DepartmentManager.

Structure

• Entities:
  • Department
  • DepartmentManager
• Relationships:
  • Department to DepartmentManager | NOTE: With the current system the edge name resulting from the creation through the meta API would be department_department_managers which is not accurate. To avoid these names we would have to do some kind of special namings for edges, prompting it to the user, for example, he would set from and the to collections on the meta API, if there's overlapping on the name, we would remove the overlapped word, making the resulting edge name: department _department _manager → department_managers

Edge definitions

Manager property on Department entity

{
  "name": "manager",
  "edge": "department_managers",
  "from": "departments",
  "to": "managers",
  "type": "one_to_one",
  "direction": "inbound"
}

Department property on Manager entity

{
  "name": "department",
  "edge": "department_managers",
  "from": "managers",
  "to": "departments",
  "type": "one_to_one",
  "direction": "outbound"
}

New types

type DepartmentManagerRelationship {
    _from: Department!
    _to: DepartmentManager!
}

New queries

type Query {
    getDepartmentManagerRel(where: { from: DepartmentIndexFilter!, to: DepartmentManagerIndexFilter! }): DepartmentManagerRelationship!
    getDepartmentsManagersRels(where: { from: DepartmentBoolExp!, to: DepartmentManagerBoolExp! }): [DepartmentManagerRelationship!]!
}

New mutations

type Mutation {
    # This would throw error if one of the entities already has a relationship (this is handled by ArangoDB indices),
    # because it's only one to one
    createDepartmentManagerRel(object: { from: DepartmentIndexFilter!, to: DepartmentManagerIndexFilter! }): DepartmentManagerRelationship!
    # If from is empty on _set, then the where has to have a filter on from because we're only changing one part of the 
    # relationship, otherwise, if to is empty on _set, then the where has to have a filter on to. If both are filled at least one 
    # of the filters both of the filters has to exist as they cannot have duplicates. In case both are empty throw an exception.
    updateDepartmentManagerRel(_set: { from: DepartmentIndexFilter, to: DepartmentManagerIndexFilter }, where: { from: DepartmentIndexFilter, to: DepartmentManagerIndexFilter }): DepartmentManagerRelationship!
    # At least one of the params has to be filled, in case they're not, throw an exception.
    removeDepartmentManagerRel(where: { from: DepartmentBoolExp, to: DepartmentManagerBoolExp }): DepartmentManagerRelationship!
}

Notes

• All the unique field validation MUST be handled by ArangoDB.
• Add validation when adding or updating a relationship to check whether the entity on from or to exists

TODO: Expand this on the issue conversation with other relationship types procedurally when implementation gets completed.

Alternatives

No response

Contribution

Yes, I will work on a PR

Keywords

graphql, relationships, integration