[
https://issues.apache.org/jira/browse/TINKERPOP-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445902#comment-16445902
]
Robert Dale commented on TINKERPOP-1948:
----------------------------------------
Or maybe types that are in `Extended` types should not be implied to have
first-class support but rather are there for transport purposes only. That is,
these are here so you can set/get these types from your data store, but don't
necessarily work in traversals. But if it's going to cause ambiguity issues,
then maybe that support should just go away completely.
IMO, Duration should really just be stored as a number. All Temporal types can
be distilled to a number. The client's Object-Graph-Mapper should handle
converting that data type.
> Sum-step should work on properties of type 'Duration'.
> ------------------------------------------------------
>
> Key: TINKERPOP-1948
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1948
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.3.2
> Reporter: Daniel C. Weber
> Priority: Minor
>
> Consider the following query:
> {code:java}
> g.inject(_P1, _P2).sum()
> {code}
> where _P1 and _P2 are bound to values of type 'gx:Duration' (Graphson).
> This will fail with the following error message:
> {code:java}
> [WARN] AbstractEvalOpProcessor - Exception processing a script on request
> [RequestMessage{, requestId=c3e3b3c1-a0dd-4029-b0b6-f7650f6866b3, op='eval',
> processor='', args={gremlin=g.inject(_P1, _P2).sum(), bindings={_P1=PT1S,
> _P2=PT2S}}}].
> java.lang.ClassCastException: java.time.Duration cannot be cast to
> java.lang.Number
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.SumGlobalStep.projectTraverser(SumGlobalStep.java:52)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.SumGlobalStep.projectTraverser(SumGlobalStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ReducingBarrierStep.processAllStarts(ReducingBarrierStep.java:84)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ReducingBarrierStep.processNextStart(ReducingBarrierStep.java:113)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:192)
> at
> org.apache.tinkerpop.gremlin.server.op.AbstractOpProcessor.handleIterator(AbstractOpProcessor.java:89)
> at
> org.apache.tinkerpop.gremlin.server.op.AbstractEvalOpProcessor.lambda$evalOpInternal$5(AbstractEvalOpProcessor.java:252)
> at
> org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.lambda$eval$0(GremlinExecutor.java:274)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This is obviously due to the fact that the Sum-steps expects its arguments to
> be of type Number, which Duration obviously is not. Since summation of
> Durations is easily available through [this
> method|[https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html#plus-java.time.Duration-]]
> it's worth consideration. The feature would save us an ugly roundtrip by
> saving longs since in some of our queries, we use sum().
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
