You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Functions id and elementId are currently defined as accepting either Node or Relationship. This can't be used by Cypher statements which have other types.
I suppose accepting Expression could be the best fit. There is a similar pattern with function keys, accepts Node, Relationship or Expression.
The text was updated successfully, but these errors were encountered:
I've tried to start making a PR but found out this seems to be a general issue across more functions. For example, startNode, endNode.
Would you agree that all functions should be able to accept Expression in general? It seems that the only benefit of having more specific function overloads is only implicit calling .getRequiredSymbolicName() inside.
Is there a usecase for unnamed Node/Relationship? Would it make sense to extend it from Expression, to assume that it's always named? There are random names generated if manual name is not provided.
Nodes and relationships on themselves are entities, and not expressions, their name is. So that's why I designed it that way.
But you're right, worth thinking about it.
Functions
id
andelementId
are currently defined as accepting eitherNode
orRelationship
. This can't be used by Cypher statements which have other types.I suppose accepting
Expression
could be the best fit. There is a similar pattern with functionkeys
, acceptsNode
,Relationship
orExpression
.The text was updated successfully, but these errors were encountered: