[
https://issues.apache.org/jira/browse/TINKERPOP-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2874.
---------------------------------------
Resolution: Duplicate
thanks for suggesting this. it's definitely a problem and we have
TINKERPOP-2234 tracking it. i've linked your issue here to it as you have a
nice write-up to consider in a design. not sure when that feature will land but
it's on the radar of things to do.
> 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
> Priority: Major
>
> 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)
