> > 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
Well, those are the top uses from what I've come across in my Gremlin career. The full GraphSON/GraphBinary list was probably a bit much to suggest because there's a ton of stuff there that likely isn't relevant to type testing in Gremlin - for example, P itself or an enum like Scope. I think I'd be into doing the graph elements (vertex, edge, property, vertexproperty, path, tree) plus the primitives and base collections (Set, List, Map). That's not a whole lot of stuff really. I think I'm also still interested in thinking through the extension model for providers as I don't want to get us painted into a corner with whatever we implement now. Actually, as I think on it now, I don't think the extension model is all that complicated. I assume we would have a form of Type interface that would be passed as P.type(Type) and Type would have it's own method for that type check. Providers would just create their own implementations of Type and expose them to users as needed. Another question might be, does adding this notion of Type create other interesting opportunities that should be considered before we keep it confined to a narrow use case (i.e. just type checking in Gremlin)? Is there a bigger picture to consider? I don't mean that we need to expand scope as part of this body of work, just that if there are other areas where this is useful it would be nice to at least have an idea as to what that might be so that it can be accounted for as part of what we're currently discussing. On Tue, May 28, 2019 at 10:51 AM Daniel Kuppitz <[email protected]> wrote: > +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 > > > > > > > > >
