[
https://issues.apache.org/jira/browse/TINKERPOP-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445597#comment-16445597
]
Daniel Weber commented on TINKERPOP-1948:
-----------------------------------------
Well, the vast number of different "time" oriented types is indeed puzzling to
me as well since they don't achieve language agnosticism but rather the
opposite. But absolute dates and durations are important, and first class IMO.
I can see your point of not creating more dependencies on those types, but
summing up durations feels rather natural and by the principle of least
surprise, summing those up should just work.
> 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
> Affects Versions: 3.3.2
> Reporter: Daniel 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)