tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Mallette <spmalle...@gmail.com>
Subject Re: Type predicates (TP3 feature suggestion)
Date Tue, 04 Jun 2019 11:55:00 GMT
For further discussion/planning:

https://issues.apache.org/jira/browse/TINKERPOP-2234

On Wed, May 29, 2019 at 9:54 AM Dmitry Novikov <dmitry.novikov@neueda.com>
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 <spmallette@gmail.com> 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 <me@gremlin.guru> 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 <spmallette@gmail.com
> >
> > > 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 <
> > > dmitry.novikov@neueda.com>
> > > > 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
> > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message