[jira] [Created] (TINKERPOP-2874) Allow to filter traversal elements by class without using a lambda

["Martin Häusler (Jira)" <ji...@apache.org>]

Martin Häusler created TINKERPOP-2874:
-----------------------------------------

             Summary: Allow to filter traversal elements by class without using a lambda
                 Key: TINKERPOP-2874
                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2874
             Project: TinkerPop
          Issue Type: New Feature
          Components: language
    Affects Versions: 3.6.2
            Reporter: Martin Häusler


I sometimes end up in traversals which contain both Vertices and Edges, and I want to filter the elements by type. To the best of my knowledge (please correct me if I'm wrong) the only way to do this at the moment is with a lambda step:
{code:java}
....filter(t -> t.get() instanceof Vertex)...{code}
 

This is somewhat problematic:
 * Lambdas don't transfer over the network
 * Lambda filters are black boxes for query optimizers, so most optimizers don't reorder them (because of potential side effects), leading to suboptimal queries

 

At the very least, we should have a way to filter {{isVertex()}} and {{{}isEdge(){}}}. An arguably even better way to do this (because it is more generic) would be {{{}hasType(Class<?> type){}}}. We could translate {{isVertex()}} to {{hasType(Vertex.class)}} and {{isEdge()}} to {{{}hasType(Edge.class){}}}.

This new step would allow to filter by type with an easy syntax. In addition:
 * it transfers well across the network (if the step stores the qualified class name). The prerequisite is that the JVM running the graph server has access to the class. This is very likely, because it only makes sense to filter for elements flowing through the traversal.
 * it can be analyzed by query optimizers, so they can treat it like a regular {{has(key, value)}} step and reorder it if necessary.

 

It is debatable whether {{hasType(Class<?> type)}} should internally check via {{instanceof}} or via {{{}getClass().equals(type){}}}. I would personally vouch for the polymorphic {{instanceof}} solution.

Non-Java drivers could accept a {{String}} instead of a {{Class<?>}} to achieve the same server-side effect. We could even have a fixed list of "well known types" which do not require fully qualified class names (e.g. {{hasType("Vertex")}} could be valid).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)