For further discussion/planning: https://issues.apache.org/jira/browse/TINKERPOP-2234
On Wed, May 29, 2019 at 9:54 AM Dmitry Novikov <[email protected]> wrote: > > 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)? > > One of opportunities could be type conversion. In addition to > `isInstance(Object)`, `Type` interface could have `convert(Object)` method > that will convert input to this type (e.g. String → Numeric) or throw > exception/return nothing if conversion is not possible. New step for type > conversion could be introduced: > > `g.V().values('age').convertTo(ProviderTypeImpl.string)` > `g.inject(1).math('_ + 1').convertTo(ProviderTypeImpl.integer)` > > On 2019/05/29 12:54:03, Stephen Mallette <[email protected]> wrote: > > > > > > 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 > > > > > > > > > > > > > > > > > > > >
