-
-
Couldn't load subscription status.
- Fork 2
Description
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:
DepartmentDepartmentManager
- Relationships:
DepartmenttoDepartmentManager| NOTE: With the current system the edge name resulting from the creation through the meta API would bedepartment_department_managerswhich 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 setfromand thetocollections 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
fromortoexists
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