[
https://issues.apache.org/jira/browse/TINKERPOP-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1957.
---------------------------------------
Resolution: Not A Problem
I can't isolate exactly why there is a discrepancy in behavior between the two
versions, but I sense that the behavior you are seeing is the correct one in
3.3.2 (which i still see in 3.3.3-SNAPSHOT). Your child traversal of
{{outE().count()}} returns a {{Long}} which means that the {{is()}} is going to
expect either {{P<Long>}} or {{Object}} given the available signatures. Your
traversal gives it a {{P<Integer>}} and Groovy makes a best guess between the
two options and ends up with a generics problem. Note that you can either
specify the {{Long}} to get by this issue or cast to {{P}}:
{code}
g.V().where(outE().count().is((P) lt(50)))
{code}
which I guess forces Groovy down the right path. Again, I'm not clear what the
discrepancy is between the two versions, but my guess is either/both of the
following:
1. There is some method signature difference between 3.2.x and 3.3.x (that i
can't seem to locate) that subtly allows Groovy to be happy to type check in
your favor for 3.3.2.
2. I've known Groovy's approach to method invocation to be somewhat
non-deterministic (seemingly) in the ScriptEngine.
Anyway, my general thinking is that when faced with these kinds of situations
with type checking I'd tend to assume that a more strict interpretation from
Groovy is the "correct" application of that function. Also, issues like this
would likely not be issues with TinkerPop as we rely completely on Groovy for
this functionality.
> Static Groovy script compilation requires long literals in predicates
> ---------------------------------------------------------------------
>
> Key: TINKERPOP-1957
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1957
> Project: TinkerPop
> Issue Type: Bug
> Components: groovy
> Affects Versions: 3.3.2
> Environment: GremlinGroovyScriptEngine with
> GroovyCompilerGremlinPlugin and COMPILE_STATIC
> Reporter: Konstantin Müller
> Priority: Major
>
> When using the GremlinGroovyScriptEngine together with
> GroovyCompilerGremlinPlugin and compilation option COMPILE_STATIC it is
> required to use long literals instead of integer literals in predicates. For
> example the following query fails during compilation:
> {noformat}
> g.V().where(outE().count().is(lt(50))){noformat}
> This gives the following error message:
> {noformat}
> Script1.groovy: 1: [Static type checking] - Cannot call
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal
> <org.apache.tinkerpop.gremlin.structure.Vertex,
> java.lang.Long>#is(org.apache.tinkerpop.gremlin.process.traversal.P
> <java.lang.Long>) with arguments
> [org.apache.tinkerpop.gremlin.process.traversal.P <java.lang.Integer>]
> @ line 1, column 13.
> g.V().where(outE().count().is(lt(50)))
> ^
> Script1.groovy: 1: [Static type checking] - Cannot find matching method
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#where(java.lang.Object).
> Please check if the declared type is correct and if the method exists.
> @ line 1, column 1.
> g.V().where(outE().count().is(lt(50))){noformat}
> Changing the query to use long literals makes the query work:
> {noformat}
> g.V().where(outE().count().is(lt(50L))){noformat}
> The original query works with version 3.2.8 or if COMPILE_STATIC is NOT used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
