+1 to have it as a predicate. Also, it may seem tempting to support as many types as possible, but I don't think we need that. Whenever I was in need of a type-check, I usually had to figure out if the element is a vertex or an edge. Hence, a small set of predefined types is probably good enough: Vertex, Edge, Property
Chers, Daniel On Tue, May 28, 2019 at 3:39 AM Stephen Mallette <[email protected]> wrote: > I've often thought of this feature more as a filter step than a predicate, > but I suppose is() would work - I'd be curious to know what Daniel > thinks... > > > TinkerPop 3 type system depends on the implementation, but there are some > common types like Vertex, Edge, Map, List, String... > > I'm not sure how we want to go about providing the available types we could > test against. I would imagine that they should be bound to the > GraphSON/GraphBinary types somehow and should be extensible to provider > types. If this sort of feature were to release without the latter, it won't > long before the questions start coming in about "how do I check for a Point > type?" or whatever. > > > outE().inV().path().unfold().is( type(Type.vertex) ) > > Of all your examples, this is the one that I feel users probably come > entangled with the most. > > > This requirement is actual for Cypher for Gremlin. > > I think this feature request has wider applicability than just > translation....we have junky workarounds for type testing. I think that I'd > like to see this change in 3.5.0. Let's see where the discussion goes as to > exactly how it would work. > > On Mon, May 27, 2019 at 9:49 AM Dmitry Novikov <[email protected]> > wrote: > > > Hello, > > > > I am aware that all of this will be improved in TinkerPop 4. > > > > Suggestion to introduce type predicates in TinkerPop 3: > > > > `...is(P.vertexType())...` or `...is(P.type(Type.vertex))...` > > > > with imports: > > > > `...is(vertexType())...` or `...is(P.type(vertex))...` > > > > TinkerPop 3 type system depends on the implementation, but there are some > > common types like Vertex, Edge, Map, List, String... > > > > Depending on the type, different steps are required to perform similar > > operations. For example, access by index: > > > > * `values(i)` to get property from vertex or edge > > * `select(i)` to get value from map > > > > In complex traversals, it might be complicated to track type. This might > > be improved by introducing type predicates: > > > > `...select('unknown').choose(mapType(), select('p'), values('p'))` > > > > Another use case - filter path elements. For example, getting all > vertices > > from path with mixed order of elements > > `g.V().limit(1).out().out().inE().outV().path().as('myPath)` is not > > trivial task. This could be achieved by: > > > > `...select('myPath').unfold().is(vertexType())` > > > > Some steps depend on type: > > > > `g.V().values('prop1').max()` will fail with `java.lang.Integer cannot be > > cast to java.lang.String` if `prop1` has different types. This could be > > addressed: > > > > `g.V().values('prop1').is(numericType()).max()` > > > > This requirement is actual for Cypher for Gremlin. I am very interested > to > > know if this requirement is language translation specific, or have other > > use cases. > > > > Please share your opinion on this. > > > > Regards, > > Dmitry > > > > >
