Specific structural types

[wgevaert]

EDIT: This pr does the following:

• Add the HasRelationshipsType and HasPropertiesType interfaces that extend the StructuralType interface.
• Change the typehints used by DeleteClause to be only variables, similar to how the documentation of CYPHER writes delete clauses. (Note that DELETE (n:LABEL {property: 'value'}) etc. do not work, only DELETE n or DELETE (n), where the latter is functionally the same as the former.)
• Change some typehints of RelationshipType and NodeType to be more specific.
• Change some typehints that used to be StructuralType to be more specific.
• Changes to Variable as discussed below
• Remove unused imports
• Sort imports
• Add commas to last entries of multiline arrays
• Add whitespace
  END OF EDIT

Make more specific structural types (HasPropertiesType and HasRelationsType) and let all three structural types implement StructuralType.

Also some codestyle fixes.

I also removed the structural types from Variable because I thought these did not make much sense. In my opinion, a variable can be the name of a structural type, but it is not itself a structural type. Maybe this does break some stuff of @transistive ? I am open for suggestions (as always).

[transistive]

I also removed the structural types from Variable because I thought these did not make much sense. In my opinion, a variable can be the name of a structural type, but it is not itself a structural type. Maybe this does break some stuff of @transistive ? I am open for suggestions (as always).

It does break some stuff.

How will you build this example?

MATCH (x:Node)
WITH x
MATCH (x) - [] -> (y:Node)

RETURN x, y

Do we have to build a new Query node with the name of the variable but no label instead of just passing the variable? That seems counterintuitive to me.

Also, why should the StructuralType be handled differently from a MapType? You can request properties on a name, but not a relationship? Continuing this logic in PHP userland, instanceof on a variable should not work as well, as it is always just a name of an entity and not the entity itself. It's an interesting philosophical discussion which I haven't thought about, but I don't think the case is as clear-cut as simply removing the StructuralType.

In my opinion as an end user, one of the main advantages of the query builder is reuse of common objects and patterns between clauses instead of having to keep track of the details such as names etc ourselves. That advantage is now lost for Variables and Structural types.

[wgevaert]

You make a good point, I never thought of passing variables as nodes. I indeed always made new nodes instead of using the variables.

I think something like

class Variable {
    protected/private function toNode(): Node {
        return Query::node()->named($this);
    }

    public function relationship(....) {
        return $this->toNode()->relationship(...);
    }
    /*....*/
    withProperties(...) {
        return $this->toNode()->withProperties(...);
    }
    /*etc*/
}

Do you agree?

[transistive]

That sounds like a great compromise to me!

Thanks

[marijnvanwezel]

I see nothing strange, but I think it would be good if @transistive also looked at it.

How should be release this version? There are some very minor BC-breaks, but do they warrant a MAJOR release?

[wgevaert]

I believe the only BC break that might hinder end-users is the renaming DeleteClause::addNode -> addVariable.

All other changes only break things that users should not do in the first place.

See also this funny comic

[transistive]

Looks great to me! 🥳