[jira] [Updated] (TINKERPOP-1486) Improve API of RemoteConnection
[
https://issues.apache.org/jira/browse/TINKERPOP-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1486:
Component/s: (was: language-variant)
> Improve API of RemoteConnection
> ---
>
> Key: TINKERPOP-1486
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1486
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.2
>Reporter: Kevin Gallardo
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Currently an implementor that wants to define a _RemoteConnection_
> implementation must return a _RemoteTraversal_ object from the
> {{RemoteConnection#submit(Bytecode)}} method.
> Thus it needs to implement a specific _RemoteTraversal_ class. When
> implementing a _RemoteTraversal_ we need to implement the methods {{next()}}
> and {{hasNext()}}. However these methods never seem to get called. Moreover,
> we need to implement the method {{nextTraverser()}} which is the one that is
> actually going to get called, but the method is not abstract and it is not
> natural to understand that this particular method needs to be implemented.
> It seems like all the other methods of _RemoteTraversal_ are never called as
> well since it is only used in _RemoteStep_, which only calls
> {{nextTraverser()}}. I wonder if we could stop using the _RemoteTraversal_
> and instead have the {{submit()}} method return a simple abstract class that
> has:
> - abstract method {{nextTraverser()}} returns _Traverser_
> - abstract method {{getSideEffects()}} returns _SideEffects_
> - possibly extend it later with others
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage
[
https://issues.apache.org/jira/browse/TINKERPOP-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1455:
Component/s: (was: language-variant)
> Provide String-based withStrategy()/withoutStrategy() for language variant
> usage
>
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why?
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to
> {{GraphTraversalSource}} by way of {{withXXX}}. For example:
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage
[
https://issues.apache.org/jira/browse/TINKERPOP-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1455.
---
Resolution: Fixed
> Provide String-based withStrategy()/withoutStrategy() for language variant
> usage
>
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why?
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to
> {{GraphTraversalSource}} by way of {{withXXX}}. For example:
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python
[
https://issues.apache.org/jira/browse/TINKERPOP-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1507.
---
Resolution: Fixed
> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
>
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process, python
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0, 3.2.3
>
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}},
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support
> "default" and "all"-type semantics in switch behavior. We need to add it to
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single
> Java file.
> {code}
> public class Tokens {
> public enum T { .. }
> public enum Order { .. }
> public enum VertexCardinality { ..}
> public enum Compare { .. }
> public enum Pick { .. }
> ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and
> will be better able to use reflection in language variant generators.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1486) Improve API of RemoteConnection
[
https://issues.apache.org/jira/browse/TINKERPOP-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1486.
---
Resolution: Fixed
> Improve API of RemoteConnection
> ---
>
> Key: TINKERPOP-1486
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1486
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.2
>Reporter: Kevin Gallardo
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Currently an implementor that wants to define a _RemoteConnection_
> implementation must return a _RemoteTraversal_ object from the
> {{RemoteConnection#submit(Bytecode)}} method.
> Thus it needs to implement a specific _RemoteTraversal_ class. When
> implementing a _RemoteTraversal_ we need to implement the methods {{next()}}
> and {{hasNext()}}. However these methods never seem to get called. Moreover,
> we need to implement the method {{nextTraverser()}} which is the one that is
> actually going to get called, but the method is not abstract and it is not
> natural to understand that this particular method needs to be implemented.
> It seems like all the other methods of _RemoteTraversal_ are never called as
> well since it is only used in _RemoteStep_, which only calls
> {{nextTraverser()}}. I wonder if we could stop using the _RemoteTraversal_
> and instead have the {{submit()}} method return a simple abstract class that
> has:
> - abstract method {{nextTraverser()}} returns _Traverser_
> - abstract method {{getSideEffects()}} returns _SideEffects_
> - possibly extend it later with others
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage
[
https://issues.apache.org/jira/browse/TINKERPOP-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reopened TINKERPOP-1455:
-
> Provide String-based withStrategy()/withoutStrategy() for language variant
> usage
>
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why?
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to
> {{GraphTraversalSource}} by way of {{withXXX}}. For example:
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1440) g:Path needs a GraphSON deserializer in Gremlin-Python
[ https://issues.apache.org/jira/browse/TINKERPOP-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1440. --- Resolution: Fixed > g:Path needs a GraphSON deserializer in Gremlin-Python > -- > > Key: TINKERPOP-1440 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1440 > Project: TinkerPop > Issue Type: Bug > Components: python >Affects Versions: 3.2.2 >Reporter: Marko A. Rodriguez >Assignee: Marko A. Rodriguez > Fix For: 3.2.3 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python
[
https://issues.apache.org/jira/browse/TINKERPOP-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1507:
Component/s: (was: language-variant)
python
> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
>
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process, python
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3, 3.3.0
>
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}},
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support
> "default" and "all"-type semantics in switch behavior. We need to add it to
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single
> Java file.
> {code}
> public class Tokens {
> public enum T { .. }
> public enum Order { .. }
> public enum VertexCardinality { ..}
> public enum Compare { .. }
> public enum Pick { .. }
> ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and
> will be better able to use reflection in language variant generators.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1440) g:Path needs a GraphSON deserializer in Gremlin-Python
[ https://issues.apache.org/jira/browse/TINKERPOP-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1440: Component/s: (was: language-variant) python > g:Path needs a GraphSON deserializer in Gremlin-Python > -- > > Key: TINKERPOP-1440 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1440 > Project: TinkerPop > Issue Type: Bug > Components: python >Affects Versions: 3.2.2 >Reporter: Marko A. Rodriguez >Assignee: Marko A. Rodriguez > Fix For: 3.2.3 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1440) g:Path needs a GraphSON deserializer in Gremlin-Python
[ https://issues.apache.org/jira/browse/TINKERPOP-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1440: - > g:Path needs a GraphSON deserializer in Gremlin-Python > -- > > Key: TINKERPOP-1440 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1440 > Project: TinkerPop > Issue Type: Bug > Components: python >Affects Versions: 3.2.2 >Reporter: Marko A. Rodriguez >Assignee: Marko A. Rodriguez > Fix For: 3.2.3 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants
[
https://issues.apache.org/jira/browse/TINKERPOP-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1523:
Component/s: (was: language-variant)
process
io
> A means of clarifying an explicit type in DSL with language variants
>
>
> Key: TINKERPOP-1523
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1523
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process
>Affects Versions: 3.2.3
>Reporter: Andy Tolbert
>Priority: Minor
>
> Depending on the host programming language, it is not possible/clear when
> implementing a gremlin language variant how a user could communicate a given
> type that is not supported in their language.
> For example, in python and javascript, there isn't a way to differentiate
> between a float and a double, yet {{Double}} and {{Float}} are valid types in
> gremlin language variants.
> In the case of deserializing, it is pretty clear what needs to be done, the
> code needs to coerce the types into a type that host language can handle, as
> specified in the [GLV
> docs|https://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/]:
> {quote}
> Language drivers are responsible for submitting Gremlin traversals to a
> TinkerPop-enabled graph system and returning results to the developer that
> are within the developer’s language’s type system. For instance, resultant
> doubles should be coerced to floats in Python.
> {quote}
> What isn't clear to me is what to do in the serialization case. As the type
> is optional, you could simply provide the numerical value and leave it to the
> backend implementation to handle it appropriately, but the type can cause the
> backend to handle things differently. For example, if the backend generates
> a schema on the fly, it might decide that a value of 2 is an {{Int32}} when
> maybe what the user wanted was a {{Int16}} for example. You could argue
> that you could predefine the schema to avoid this, but lets ignore that for a
> moment.
> I think it would be nice is if there was some way in the DSL for the user to
> communicate the underlying type that should be used in the traversal, i.e.:
> {code:javascript}
> g.E().has("weight", asFloat(0.2))
> {code}
> {{asFloat}} and other {{asXXX}} methods could be a way for a host environment
> without an adequate type system to communicate the underlying type. Also, a
> {{as(typename)}} method could be useful for communicating arbitrary types
> that are maybe implementation specific.
> Any implementation could provide this functionality themselves, but I'm
> wondering if it would be useful to make this part of the specification of
> things a GLV implementation could provide, that way there is a somewhat
> standard way of communicating types in absence of types in the host language.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure
[
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reopened TINKERPOP-1278:
-
> Implement Gremlin-Python and general purpose language variant test
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model
> presented in
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
> Moreover, on every {{mvn clean install}}, the code for these variants is
> generated.
> Given the desire to separate language variants from language drivers, I think
> that a language driver for each variant above should be "plugable." Moreover,
> we should provide one driver implementation for each -- simple GremlinServer
> REST.
> {code}
> gremlin-variants/
> gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
> gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
> gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we
> have to implement each {{g_V_out_repeatXasXaXX}} test case in
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to
> convert all those tests from Gremlin-Java to the respective host language?
> However, even if we do that, we still have the problem of how to test the
> returned results.
> I think what we should test the returned results using the JVM. For instance,
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a
> massive headache. All we have to do is create a {{GraphProvider}} that uses
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1449) Streamline gremlin-python build
[ https://issues.apache.org/jira/browse/TINKERPOP-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1449: - > Streamline gremlin-python build > --- > > Key: TINKERPOP-1449 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1449 > Project: TinkerPop > Issue Type: Improvement > Components: build-release, python >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.2.3 > > > Seems like there is a bit of extra processing and stuff going on in the > gremlin-python build automation. Most notably: > 1. there are two executions of jython when only one seems necessary > 2. doing a -DskipTests skips more stuff than it probably should - would be > nice to skip testing and still get valid packaging. not sure how probably > this will be > 3. there's a number of seemingly superfluous settings that i don't believe > serve any purpose and should be removed. validate that that they can be > removed and if not, figure out what they are so the don't seem so superfluous > any more. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure
[
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1278:
Component/s: (was: language-variant)
python
> Implement Gremlin-Python and general purpose language variant test
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model
> presented in
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
> Moreover, on every {{mvn clean install}}, the code for these variants is
> generated.
> Given the desire to separate language variants from language drivers, I think
> that a language driver for each variant above should be "plugable." Moreover,
> we should provide one driver implementation for each -- simple GremlinServer
> REST.
> {code}
> gremlin-variants/
> gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
> gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
> gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we
> have to implement each {{g_V_out_repeatXasXaXX}} test case in
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to
> convert all those tests from Gremlin-Java to the respective host language?
> However, even if we do that, we still have the problem of how to test the
> returned results.
> I think what we should test the returned results using the JVM. For instance,
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a
> massive headache. All we have to do is create a {{GraphProvider}} that uses
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure
[
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1278.
---
Resolution: Fixed
> Implement Gremlin-Python and general purpose language variant test
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model
> presented in
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
> Moreover, on every {{mvn clean install}}, the code for these variants is
> generated.
> Given the desire to separate language variants from language drivers, I think
> that a language driver for each variant above should be "plugable." Moreover,
> we should provide one driver implementation for each -- simple GremlinServer
> REST.
> {code}
> gremlin-variants/
> gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
> gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
> gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we
> have to implement each {{g_V_out_repeatXasXaXX}} test case in
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to
> convert all those tests from Gremlin-Java to the respective host language?
> However, even if we do that, we still have the problem of how to test the
> returned results.
> I think what we should test the returned results using the JVM. For instance,
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a
> massive headache. All we have to do is create a {{GraphProvider}} that uses
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1448) gremlin-python should be Python 2/3 compatible
[ https://issues.apache.org/jira/browse/TINKERPOP-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1448: Component/s: (was: language-variant) python > gremlin-python should be Python 2/3 compatible > -- > > Key: TINKERPOP-1448 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1448 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.2.2 >Reporter: David M. Brown >Assignee: David M. Brown > Fix For: 3.2.3 > > > As discussed here, it is simple to maintain Python 2/3 compatibility for > gremlin-python GLV: > https://lists.apache.org/thread.html/263739a38133be620dd32640fe997388e76b20379a3dae44b10d4442@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants
[
https://issues.apache.org/jira/browse/TINKERPOP-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1523.
---
Resolution: Won't Do
> A means of clarifying an explicit type in DSL with language variants
>
>
> Key: TINKERPOP-1523
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1523
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process
>Affects Versions: 3.2.3
>Reporter: Andy Tolbert
>Priority: Minor
>
> Depending on the host programming language, it is not possible/clear when
> implementing a gremlin language variant how a user could communicate a given
> type that is not supported in their language.
> For example, in python and javascript, there isn't a way to differentiate
> between a float and a double, yet {{Double}} and {{Float}} are valid types in
> gremlin language variants.
> In the case of deserializing, it is pretty clear what needs to be done, the
> code needs to coerce the types into a type that host language can handle, as
> specified in the [GLV
> docs|https://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/]:
> {quote}
> Language drivers are responsible for submitting Gremlin traversals to a
> TinkerPop-enabled graph system and returning results to the developer that
> are within the developer’s language’s type system. For instance, resultant
> doubles should be coerced to floats in Python.
> {quote}
> What isn't clear to me is what to do in the serialization case. As the type
> is optional, you could simply provide the numerical value and leave it to the
> backend implementation to handle it appropriately, but the type can cause the
> backend to handle things differently. For example, if the backend generates
> a schema on the fly, it might decide that a value of 2 is an {{Int32}} when
> maybe what the user wanted was a {{Int16}} for example. You could argue
> that you could predefine the schema to avoid this, but lets ignore that for a
> moment.
> I think it would be nice is if there was some way in the DSL for the user to
> communicate the underlying type that should be used in the traversal, i.e.:
> {code:javascript}
> g.E().has("weight", asFloat(0.2))
> {code}
> {{asFloat}} and other {{asXXX}} methods could be a way for a host environment
> without an adequate type system to communicate the underlying type. Also, a
> {{as(typename)}} method could be useful for communicating arbitrary types
> that are maybe implementation specific.
> Any implementation could provide this functionality themselves, but I'm
> wondering if it would be useful to make this part of the specification of
> things a GLV implementation could provide, that way there is a somewhat
> standard way of communicating types in absence of types in the host language.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants
[
https://issues.apache.org/jira/browse/TINKERPOP-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reopened TINKERPOP-1523:
-
> A means of clarifying an explicit type in DSL with language variants
>
>
> Key: TINKERPOP-1523
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1523
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process
>Affects Versions: 3.2.3
>Reporter: Andy Tolbert
>Priority: Minor
>
> Depending on the host programming language, it is not possible/clear when
> implementing a gremlin language variant how a user could communicate a given
> type that is not supported in their language.
> For example, in python and javascript, there isn't a way to differentiate
> between a float and a double, yet {{Double}} and {{Float}} are valid types in
> gremlin language variants.
> In the case of deserializing, it is pretty clear what needs to be done, the
> code needs to coerce the types into a type that host language can handle, as
> specified in the [GLV
> docs|https://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/]:
> {quote}
> Language drivers are responsible for submitting Gremlin traversals to a
> TinkerPop-enabled graph system and returning results to the developer that
> are within the developer’s language’s type system. For instance, resultant
> doubles should be coerced to floats in Python.
> {quote}
> What isn't clear to me is what to do in the serialization case. As the type
> is optional, you could simply provide the numerical value and leave it to the
> backend implementation to handle it appropriately, but the type can cause the
> backend to handle things differently. For example, if the backend generates
> a schema on the fly, it might decide that a value of 2 is an {{Int32}} when
> maybe what the user wanted was a {{Int16}} for example. You could argue
> that you could predefine the schema to avoid this, but lets ignore that for a
> moment.
> I think it would be nice is if there was some way in the DSL for the user to
> communicate the underlying type that should be used in the traversal, i.e.:
> {code:javascript}
> g.E().has("weight", asFloat(0.2))
> {code}
> {{asFloat}} and other {{asXXX}} methods could be a way for a host environment
> without an adequate type system to communicate the underlying type. Also, a
> {{as(typename)}} method could be useful for communicating arbitrary types
> that are maybe implementation specific.
> Any implementation could provide this functionality themselves, but I'm
> wondering if it would be useful to make this part of the specification of
> things a GLV implementation could provide, that way there is a somewhat
> standard way of communicating types in absence of types in the host language.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1425) Use trailing underscores in gremlin-python
[ https://issues.apache.org/jira/browse/TINKERPOP-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1425: Component/s: (was: language-variant) python > Use trailing underscores in gremlin-python > -- > > Key: TINKERPOP-1425 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1425 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: Marko A. Rodriguez > Fix For: 3.2.2 > > > As per discussion on TINKERPOP-1278 it seems more pythonesque to use trailing > underscores rather than leading. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1425) Use trailing underscores in gremlin-python
[ https://issues.apache.org/jira/browse/TINKERPOP-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1425. --- Resolution: Fixed > Use trailing underscores in gremlin-python > -- > > Key: TINKERPOP-1425 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1425 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: Marko A. Rodriguez > Fix For: 3.2.2 > > > As per discussion on TINKERPOP-1278 it seems more pythonesque to use trailing > underscores rather than leading. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1448) gremlin-python should be Python 2/3 compatible
[ https://issues.apache.org/jira/browse/TINKERPOP-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1448. --- Resolution: Fixed > gremlin-python should be Python 2/3 compatible > -- > > Key: TINKERPOP-1448 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1448 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.2.2 >Reporter: David M. Brown >Assignee: David M. Brown > Fix For: 3.2.3 > > > As discussed here, it is simple to maintain Python 2/3 compatibility for > gremlin-python GLV: > https://lists.apache.org/thread.html/263739a38133be620dd32640fe997388e76b20379a3dae44b10d4442@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1425) Use trailing underscores in gremlin-python
[ https://issues.apache.org/jira/browse/TINKERPOP-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1425: - > Use trailing underscores in gremlin-python > -- > > Key: TINKERPOP-1425 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1425 > Project: TinkerPop > Issue Type: Improvement > Components: language-variant >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: Marko A. Rodriguez > Fix For: 3.2.2 > > > As per discussion on TINKERPOP-1278 it seems more pythonesque to use trailing > underscores rather than leading. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1665) Remove unittest from Gremlin-Python tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1665: - > Remove unittest from Gremlin-Python tests > - > > Key: TINKERPOP-1665 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1665 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.2.4 >Reporter: David M. Brown >Assignee: David M. Brown >Priority: Minor > Fix For: 3.2.5 > > > Since we are using Pytest, it is isn't necessary to use Python's unittest > module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1665) Remove unittest from Gremlin-Python tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1665: Component/s: (was: language-variant) python > Remove unittest from Gremlin-Python tests > - > > Key: TINKERPOP-1665 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1665 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.2.4 >Reporter: David M. Brown >Assignee: David M. Brown >Priority: Minor > Fix For: 3.2.5 > > > Since we are using Pytest, it is isn't necessary to use Python's unittest > module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1567) GraphSON deserialization fails with within('a')
[
https://issues.apache.org/jira/browse/TINKERPOP-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1567:
Component/s: (was: language-variant)
python
> GraphSON deserialization fails with within('a')
> ---
>
> Key: TINKERPOP-1567
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1567
> Project: TinkerPop
> Issue Type: Bug
> Components: python, server
>Affects Versions: 3.2.3
> Environment: Demonstrated on Ubuntu 14.04 and Debian Testing
>Reporter: Branden Moore
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.4
>
>
> Using the gremlin-python interface, when I attempt to run an example from the
> Documentation of {{where}}:
> {code}
> g.withSideEffect('a','josh','peter']).V(1).out('created').in_('created').values('name').where(P.within('a')).toList()
> {code}
> The server returns a deserialization error:
> {noformat}
> {{[WARN] OpExecutorHandler - Could not deserialize the JSON value as
> required. Nested exception:
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingExce[18/147]
> ould not deserialize the JSON value as required. Nested exception:
> java.lang.IllegalStateException:
> org.apache.tinkerpop.gremlin.process.traversal.P.within(java.la
> ng.Object)
>
> at [Source:
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
> line: 1, column: 248] (through reference chain: java.util.
> LinkedHashMap["step"]->java.util.ArrayList[4]->java.util.ArrayList[1])
>
> at [Source:
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
> line: 1, column: 248]
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not
> deserialize the JSON value as required. Nested exception:
> org.apache.tinkerpop.shaded.
> jackson.databind.JsonMappingException: Could not deserialize the JSON value
> as required. Nested exception: java.lang.IllegalStateException:
> org.apache.tinkerpop.gr
> emlin.process.traversal.P.within(java.lang.Object)
>
> at [Source:
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
> line: 1, column: 248] (through reference chain:
> java.util.LinkedHashMap["step"]->java.util.ArrayList[4]->java.util.ArrayList[1])
> at [Source:
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
> line: 1, column: 248]
> at
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException.from(JsonMappingException.java:216)
>at
> org.apache.tinkerpop.shaded.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:883)
>at
> org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserialize(GraphSONTypeDeserializer.java:195)
> at
> org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserializeTypedFromAny(GraphSONTypeDeserializer.java:102)
> at
> org.apache.tinkerpop.shaded.jackson.databind.deser.std.StdDeserializer.deserializeWithType(StdDeserializer.java:120)
> at
> org.apache.tinkerpop.shaded.jackson.databind.deser.impl.TypeWrappedDeserializer.deserialize(TypeWrappedDeserializer.java:42)
> at
> org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3789)
> at
> org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2779)
> at
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:339)
> at
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
> at
>
[jira] [Updated] (TINKERPOP-1618) Remove groovy dependency from gremlin-python
[
https://issues.apache.org/jira/browse/TINKERPOP-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1618:
Component/s: (was: language-variant)
python
> Remove groovy dependency from gremlin-python
>
>
> Key: TINKERPOP-1618
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1618
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.5
>
>
> {{gremlin-python}} currently depends on groovy for its code generation needs.
> This dependency could probably be removed in favor of the scripts being
> executed as part of the gmavenplus plugin directly in the pom.xml. In this
> way the gremlin-python jar would no longer have a dependency on groovy.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1665) Remove unittest from Gremlin-Python tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1665. --- Resolution: Fixed > Remove unittest from Gremlin-Python tests > - > > Key: TINKERPOP-1665 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1665 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.2.4 >Reporter: David M. Brown >Assignee: David M. Brown >Priority: Minor > Fix For: 3.2.5 > > > Since we are using Pytest, it is isn't necessary to use Python's unittest > module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1618) Remove groovy dependency from gremlin-python
[
https://issues.apache.org/jira/browse/TINKERPOP-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1618.
---
Resolution: Done
> Remove groovy dependency from gremlin-python
>
>
> Key: TINKERPOP-1618
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1618
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.5
>
>
> {{gremlin-python}} currently depends on groovy for its code generation needs.
> This dependency could probably be removed in favor of the scripts being
> executed as part of the gmavenplus plugin directly in the pom.xml. In this
> way the gremlin-python jar would no longer have a dependency on groovy.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1567) GraphSON deserialization fails with within('a')
[
https://issues.apache.org/jira/browse/TINKERPOP-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reopened TINKERPOP-1567:
-
> GraphSON deserialization fails with within('a')
> ---
>
> Key: TINKERPOP-1567
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1567
> Project: TinkerPop
> Issue Type: Bug
> Components: python, server
>Affects Versions: 3.2.3
> Environment: Demonstrated on Ubuntu 14.04 and Debian Testing
>Reporter: Branden Moore
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.4
>
>
> Using the gremlin-python interface, when I attempt to run an example from the
> Documentation of {{where}}:
> {code}
> g.withSideEffect('a','josh','peter']).V(1).out('created').in_('created').values('name').where(P.within('a')).toList()
> {code}
> The server returns a deserialization error:
> {noformat}
> {{[WARN] OpExecutorHandler - Could not deserialize the JSON value as
> required. Nested exception:
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingExce[18/147]
> ould not deserialize the JSON value as required. Nested exception:
> java.lang.IllegalStateException:
> org.apache.tinkerpop.gremlin.process.traversal.P.within(java.la
> ng.Object)
>
> at [Source:
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
> line: 1, column: 248] (through reference chain: java.util.
> LinkedHashMap["step"]->java.util.ArrayList[4]->java.util.ArrayList[1])
>
> at [Source:
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
> line: 1, column: 248]
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not
> deserialize the JSON value as required. Nested exception:
> org.apache.tinkerpop.shaded.
> jackson.databind.JsonMappingException: Could not deserialize the JSON value
> as required. Nested exception: java.lang.IllegalStateException:
> org.apache.tinkerpop.gr
> emlin.process.traversal.P.within(java.lang.Object)
>
> at [Source:
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
> line: 1, column: 248] (through reference chain:
> java.util.LinkedHashMap["step"]->java.util.ArrayList[4]->java.util.ArrayList[1])
> at [Source:
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
> line: 1, column: 248]
> at
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException.from(JsonMappingException.java:216)
>at
> org.apache.tinkerpop.shaded.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:883)
>at
> org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserialize(GraphSONTypeDeserializer.java:195)
> at
> org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserializeTypedFromAny(GraphSONTypeDeserializer.java:102)
> at
> org.apache.tinkerpop.shaded.jackson.databind.deser.std.StdDeserializer.deserializeWithType(StdDeserializer.java:120)
> at
> org.apache.tinkerpop.shaded.jackson.databind.deser.impl.TypeWrappedDeserializer.deserialize(TypeWrappedDeserializer.java:42)
> at
> org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3789)
> at
> org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2779)
> at
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:339)
> at
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
> at
>
[jira] [Updated] (TINKERPOP-1343) A more efficient StarGraph serialization representation.
[
https://issues.apache.org/jira/browse/TINKERPOP-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1343:
Fix Version/s: (was: 3.3.1)
> A more efficient StarGraph serialization representation.
>
>
> Key: TINKERPOP-1343
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1343
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
> Labels: breaking
>
> {{StarGraph}} is used by the Hadoop {{GraphComputers}} and represents a
> vertex, its properties, its incident edges, and their properties. In essence,
> one "row of an adjacency list."
> Here are some ideas on how to make the next version of the serialization
> format more efficient.
> 1. For all Element ids, we currently use {{kryo.readClassAndObject(...)}}.
> This is bad because we have to write the class with each id. It would be
> better if the {{StarGraph}} had metadata like {{vertexIdClass}},
> {{vertexPropertyIdClass}}, and {{edgeIdClass}}. Now for every vertex we are
> serializing three class, but the benefit is that every id class is now known
> and we can use {{kryo.readObject(..., xxxIdClass)}}.
> 2. Edges and VertexProperties are written out as {{[ edgeLabel[ edge[ id,
> otherVertexId]\*]\*}} and {{[ propertyKey[ vertexProperty[
> id,propertyValue]\*]\*}}, respectively. This ensures we don't write so many
> strings as all edges/vertex properties are grouped by label. However, we do
> NOT do this for edge properties nor vertex property properties. We simply
> write out the {{Map>}} which is
> {{Map>}}. Since we have to choose
> between grouping by edgeId or by propertyKey, we should keep it as it is, but
> create a "meta map" that allows us to represent all property keys in a, e.g.,
> {{int}} space. Thus, {{Map>}}
> where we also have a {{Map}} that is serialized
> with the {{StarGraph}}.
> There are a few other tickets around optimizing {{StarGraph}} here:
> https://issues.apache.org/jira/browse/TINKERPOP-1128 (making {{GraphFilters}}
> more efficient)
> https://issues.apache.org/jira/browse/TINKERPOP-1122 (pointless bits and
> {{StarGraph}} should never auto-generate IDs as the ID space is distributed).
> https://issues.apache.org/jira/browse/TINKERPOP-1287 (related to heap usage
> and clock cycles -- not serialization).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1346) Create custom ReferenceXXX GryoSerializers
[
https://issues.apache.org/jira/browse/TINKERPOP-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1346:
Fix Version/s: (was: 3.3.1)
> Create custom ReferenceXXX GryoSerializers
> --
>
> Key: TINKERPOP-1346
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1346
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, structure
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
> Labels: breaking
>
> Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] +
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] +
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
> {code}
> Assuming {{Long}} Element ids, the math says:
> {code}
> 48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8
> bytes [long]) + 4 bytes + (4 bytes + 8 bytes [long])
> {code}
> We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] +
> KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
> {code}
> The math says:
> {code}
> 36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] +
> 8 bytes [long]
> {code}
> Similar techniques would apply to {{ReferenceVertexProperty}} and
> {{ReferenceProperty}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1768) Bump to Jackson 2.8.10
[ https://issues.apache.org/jira/browse/TINKERPOP-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1768. --- Resolution: Done > Bump to Jackson 2.8.10 > -- > > Key: TINKERPOP-1768 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1768 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.2.6 >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.2.7, 3.3.1 > > > Jackson 2.8.10 has some important bug fixes - hoping for a fix for > TINKERPOP-1509 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1122) StarGraph has a Long nextId. That is pointless and a waste of 64-bits.
[
https://issues.apache.org/jira/browse/TINKERPOP-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1122:
Fix Version/s: (was: 3.3.1)
> StarGraph has a Long nextId. That is pointless and a waste of 64-bits.
> --
>
> Key: TINKERPOP-1122
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1122
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop, io, structure
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
> Labels: breaking
>
> {code}
> protected Long nextId = 0l;
> private Long nextId() {
> return this.nextId++;
> }
> {code}
> This makes no sense as then each StarGraph in the full Graph will have
> similar ids! Moreover, what is referencing what when the adjacent vertices
> are just arbitrary long ids?!! We should require that StarGraph get provided
> ids for vertices (and perhaps edges)... We ensure no inconsistencies and we
> save 64-bits.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1128) Change the Gryo serialization for StarGraph (Vertex, Properties, then Edges)
[
https://issues.apache.org/jira/browse/TINKERPOP-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1128:
Fix Version/s: (was: 3.3.1)
> Change the Gryo serialization for StarGraph (Vertex, Properties, then Edges)
>
>
> Key: TINKERPOP-1128
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1128
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
> Labels: breaking
>
> Right now we serialize first the vertex, then its edges, then its properties.
> We should do vertex, properties, edges. Why? If we know that the vertex is to
> be filtered (which is an analysis of its label/id/properties), then we can
> skip over analyzing its edges. Right now, we may do all this work
> deserializing edges only to realize that the {{GraphFilter}} says that the
> vertex is filtered. Dah, pointless clock cycles -- especially when edge sets
> can be massive.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1515) One test suite to rule them all
[ https://issues.apache.org/jira/browse/TINKERPOP-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1515: Fix Version/s: (was: 3.3.1) > One test suite to rule them all > --- > > Key: TINKERPOP-1515 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1515 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: stephen mallette > Labels: breaking > > Make an attempt at an uber test module that would collapse all provider > related tests into a single module. I say "attempt" as I'm not completely > aware of what kinds of dependency conflicts I'll see try to do this. > Consider TINKERPOP-1410 in doing this. > Obviously this change would be breaking if modules are combined and package > renaming occurs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1344) ReferenceYYYXXX for better message passing
[
https://issues.apache.org/jira/browse/TINKERPOP-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1344:
Fix Version/s: (was: 3.3.1)
> ReferenceYYYXXX for better message passing
> --
>
> Key: TINKERPOP-1344
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1344
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>
> In https://issues.apache.org/jira/browse/TINKERPOP-1343, I was saying that it
> would be nice to have the element id type be known so we can do
> {{writeObject()}} as opposed to {{writeObjectAndClass()}}. I think we could
> do some good with a hiearchy of classes like:
> {code}
> ReferenceIntVertex
> ReferenceLongVertex
> ReferenceVertex (Object -- what we have now)
> ReferenceUUIDVertex
> ...
> {code}
> ...likewise for Edge, VertexProperty...
> This will save us an extra 32-bits (4 byte int) on the serialization of
> messages during OLAP message pass as that is all {{ReferenceXXX}} based.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1118) SparkGraphComputer should use StarGraph, not VertexWritable.
[
https://issues.apache.org/jira/browse/TINKERPOP-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1118:
Fix Version/s: (was: 3.3.1)
> SparkGraphComputer should use StarGraph, not VertexWritable.
>
>
> Key: TINKERPOP-1118
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1118
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
> Labels: breaking
>
> {{SparkGraphComputer}} input RDDs are typed as:
> {code}
> JavaPairRDD
> {code}
> The {{VertexWritable}} usage is a vestige from Hadoop and Giraph. In Spark,
> we don't need to have this wrapper and thus, we can reduce the overhead (one
> less object header) by making the input RDDs typed as:
> {code}
> JavaPairRDD
> {code}
> This would be a breaking change for graph providers that implement their own
> {{InputRDD}} and {{OutputRDD}}, however, the fix is trivial. Instead of {{new
> VertexWritable(vertex)}}, they would simply do {{StarGraph.of(vertex)}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1074) More contractual testing/specifications around Persist and ResultGraph.
[
https://issues.apache.org/jira/browse/TINKERPOP-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1074:
Fix Version/s: (was: 3.2.7)
> More contractual testing/specifications around Persist and ResultGraph.
> ---
>
> Key: TINKERPOP-1074
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1074
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>
> A {{ComputerResult}} references two objects: a graph and a memory. The graph
> is the resultant computed graph and the memory contains all the sideEffect
> data from the computation (if any).
> Right now, we have the following {{Persist}} options: {{NOTHING}},
> {{VERTEX_PROPERTIES}}, {{EDGES}}. We also have the following {{ResultGraph}}
> options: {{ORIGINAL}}, {{NEW}}.
> * NOTHING + ORIGINAL = ComputerResult contains original graph reference.
> * NOTHING + NEW = ?? No test to force what this means! Should be
> {{EmptyGraph.instance()}}.
> * VERTEX_PROPERTIES + ORIGINAL = ComputerResult contains original graph, but
> the computed vertex properties have been "saved" to it. (no contractual test
> cases here either!)
> * VERTEX_PROPERTIES + NEW = ComputerResult contains new graph with only
> vertices and their properties.
> * EDGES + NEW = ComputerResult contains new graph with vertices, edges, and
> their properties.
> * EDGES + ORIGINAL = ComputerResult contains original graph, but the computed
> vertex properties and edges have been "saved" to it. (no contractual test
> cases here either!)
> {{TinkerGraphComputer}} is the only system that supports all the above
> configuration combinations. Add test cases to {{GraphComputerTest}} that
> verify the behavior of all combinations.
> HOWEVER -- should we really respect ORIGINAL+PERSIST? Most providers
> will use {{BulkLoaderVertexProgram}} to write the computed graph back to the
> original graph. If there are TWO ways of doing this, this seems bad? In fact,
> the way that TinkerGraphComputer writes the computed graph back to the
> original graph is nearly identical to how it BulkLoaderVertexProgram works.
> Thus, I'm wondering if we simply get rid the concept of {{ResultGraph}} and
> ONLY have {{Persist}}.
> * Persist.NOTHING: Returns the original graph in {{ComputerResult}}.
> * Persist.VERTEX_PROPERTIES: Returns a new graph with only vertices and
> properties.
> * Persist.EDGES: Returns a new graph with vertices, edges, and their
> properties.
> For in-memory graphs like {{TinkerGraph}}, "new graph" can mean the original
> graph with the {{GraphView}} overlay. Thus, its not really a full copy of the
> original graph. Moreover, Persist.NOTHING just garbage collects the GraphView
> and thus, the original graph.
> --
> Next, what does {{Persist}} mean for memory? Remember, {{ComputerResult}}
> also has a reference to sideEffect memory. What if you want to run a job, NOT
> persist the graph, but persist the memory only. I think we should ALWAYS
> assume memory persistence. For TinkerGraph, that means the the
> ComputerResult.memory() has a HashMap of memory values. For Giraph/Spark,
> that means that the {{Storage}} will always have resultant sideEffect data in
> the output directory even if there is no graph.
> * {{NOTHING}}: persist memory and return the original graph.
> * {{VERTEX_PROPERTIES}}: persist memory and return new graph of just vertex
> properties.
> * {{EDGES}}: persist memory and return new graph of vertex properties, and
> edges.
> Decisions, decisions, decisions
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1717) Update name and link of DynamoDB storage backend in landing page
[ https://issues.apache.org/jira/browse/TINKERPOP-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1717: Fix Version/s: (was: 3.3.1) > Update name and link of DynamoDB storage backend in landing page > > > Key: TINKERPOP-1717 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1717 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.2.3 >Reporter: Alexander Patrikalakis >Priority: Minor > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Amazon have released DynamoDB storage backends compatible with JG 0.1.0 and > 0.1.1: > https://mvnrepository.com/artifact/com.amazonaws/dynamodb-janusgraph-storage-backend/1.0.0 > https://mvnrepository.com/artifact/com.amazonaws/dynamodb-janusgraph-storage-backend/1.1.0 > Also, we have renamed the repository on GitHub to > dynamodb-janusgraph-storage-backend for git history continuity. So, can we > update the names and links on the landing page? Also minor, I would like to > update the capitalization of "storage backend" -> "Storage Backend" > Before: > [Titan (Amazon)](https://github.com/awslabs/dynamodb-titan-storage-backend/) > - The Amazon DynamoDB storage backend for Titan. > After: > [JanusGraph > (Amazon)](https://github.com/awslabs/dynamodb-janusgraph-storage-backend/) - > The Amazon DynamoDB Storage Backend for JanusGraph. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1187) Create a GraphComputer Tutorial
[ https://issues.apache.org/jira/browse/TINKERPOP-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1187: Fix Version/s: (was: 3.2.7) > Create a GraphComputer Tutorial > --- > > Key: TINKERPOP-1187 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1187 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.1.1-incubating >Reporter: Marko A. Rodriguez >Assignee: Marko A. Rodriguez > > We should create a GraphComputer tutorial that discusses: > 1. GraphComputer, Memory, and VertexPrograms. > 2. Explains how Traversals are compiled to TraversalVertexPrograms. > 3. The mechanics of a TraversalVertexProgram. > 4. How to write your own VertexProgram. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-967) Support nested-repeat() structures
[
https://issues.apache.org/jira/browse/TINKERPOP-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-967:
---
Fix Version/s: (was: 3.2.7)
> Support nested-repeat() structures
> --
>
> Key: TINKERPOP-967
> URL: https://issues.apache.org/jira/browse/TINKERPOP-967
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> All the internal plumbing is staged for this to happen, we just haven't gone
> all the way. In short, a {{NESTED_LOOP}} traverser has an internal
> {{loopStack}} where {{repeat(repeat())}} will have a {{loopStack}} of two.
> The {{it.loops()}} checks of the internal repeat will always check the top of
> the stack and when its done repeating will delete its counter off the top of
> the stack.
> [~dkuppitz]'s work on {{LoopStep}} will be backwards compatible. In
> {{RepeatStep}} we will support:
> {code}
> repeat('a',out('knows').repeat('b',out('parent')))
> {code}
> and thus, things like {{loops('a')}} as well as {{times('a',2)}}. Note that
> naming the loop stack will be a super rare case as most people will just
> assume standard nested looping semantics with a push/pop stack.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1535) Bump to support Giraph 1.2.0.
[ https://issues.apache.org/jira/browse/TINKERPOP-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1535: Fix Version/s: (was: 3.3.1) > Bump to support Giraph 1.2.0. > - > > Key: TINKERPOP-1535 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1535 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop >Affects Versions: 3.2.3 >Reporter: Marko A. Rodriguez >Assignee: Marko A. Rodriguez > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1141) HadoopRemoteAcceptor is overly complicated. Simplify with ComputerResult as a SideEffect in OLAP Traversal.
[
https://issues.apache.org/jira/browse/TINKERPOP-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1141:
Fix Version/s: (was: 3.2.7)
> HadoopRemoteAcceptor is overly complicated. Simplify with ComputerResult as a
> SideEffect in OLAP Traversal.
> ---
>
> Key: TINKERPOP-1141
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1141
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop, process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>
> {{HadoopRemoteAcceptor}} is overly complicated. I think that instead of
> making {{ComputerResult}} a value in the Console, we should just add
> {{ComputerResult}} to the OLAP {{Traversal}}.
> {code}
> t = g.V().out().count()
> result = t.getSideEffects().get('~computerResult')
> {code}
> For most people, they will never use this as computer result memory is
> already in the sideEffects. However, {{ComputerResult}} also has other
> information like iteration, runtime, and graph.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1129) Make StarGraphGraphSONSerializer and connect it up with GraphFilter and GraphSONInputFormat
[
https://issues.apache.org/jira/browse/TINKERPOP-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1129:
Fix Version/s: (was: 3.2.7)
> Make StarGraphGraphSONSerializer and connect it up with GraphFilter and
> GraphSONInputFormat
> ---
>
> Key: TINKERPOP-1129
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1129
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop, io
>Affects Versions: 3.2.5
>Reporter: Marko A. Rodriguez
>
> Currently, only {{ScriptInputFormat}} and {{GryoInputFormat}} are able to
> leverage {{GraphFilter}} "close to the metal." We should do the same for
> {{GraphSONInputFormat}} via {{StarGraphGraphSONSerializer}}. It shouldn't be
> that hard, just need to do it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-963) SubgraphTraversalAnalyzer to determine what is really required from a traversal.
[
https://issues.apache.org/jira/browse/TINKERPOP-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-963:
---
Fix Version/s: (was: 3.2.7)
> SubgraphTraversalAnalyzer to determine what is really required from a
> traversal.
>
>
> Key: TINKERPOP-963
> URL: https://issues.apache.org/jira/browse/TINKERPOP-963
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> This idea is dependent on the work in TINKERPOP3-962 being complete.
> The idea is that there should be a {{SubgraphTraversalAnalyzer}}-type step
> that for a {{traversal}} returns a
> {{Pair,Traversal>}} that defines two
> "filters" that contain the subgraph that the traversal will execute in.
> For instance.
> {code}
> g.V().hasLabel("person").out("pets").hasLabel("dog")
> {code}
> {{SubgraphTraversalAnalyzer}} would return
> {code}
> Pair.with(
> hasLabel("person","dog"),
> hasLabel("pets"))
> {code}
> The difficulty with this ticket is that TinkerPop does NOT make any
> assumptions about a schema. For instance, if the user did this:
> {code}
> g.V().hasLabel("person").out("pets")
> {code}
> Then the best we could return is:
> {code}
> Pair.with(
> identity(),
> hasLabel("pets"))
> {code}
> cc/ [~mbroecheler]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1711) map(union(fold())) bug
[
https://issues.apache.org/jira/browse/TINKERPOP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1711:
Fix Version/s: (was: 3.2.7)
> map(union(fold())) bug
> --
>
> Key: TINKERPOP-1711
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1711
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.5
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>
> Actual:
> {code:java}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().valueMap()
> ==>[name:[marko],age:[29]]
> ==>[name:[vadas],age:[27]]
> ==>[name:[lop],lang:[java]]
> ==>[name:[josh],age:[32]]
> ==>[name:[ripple],lang:[java]]
> ==>[name:[peter],age:[35]]
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[[],vadas]
> ==>[lop,[java]]
> ==>[[],josh]
> ==>[ripple,[java]]
> ==>[[],peter]
> {code}
> Expected:
> {code:java}
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[vadas,[]]
> ==>[lop,[java]]
> ==>[josh,[]]
> ==>[ripple,[java]]
> ==>[peter,[]]
> {code}
> List reference:
> https://groups.google.com/forum/#!topic/gremlin-users/L_fESS6ta0A
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1098) Local Filters
[
https://issues.apache.org/jira/browse/TINKERPOP-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1098:
Fix Version/s: (was: 3.2.7)
> Local Filters
> -
>
> Key: TINKERPOP-1098
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1098
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Daniel Kuppitz
>
> We should provide local filter steps. Currently, if you want to filter
> elements from paths or lists (or maps?), you have to do
> {{unfold().filter().fold()}}.
> Not sure if that only affects {{filter()}}, or also {{has()}}, {{hasNot()}},
> {{where()}}, ...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-878) Refactor Gremlin Server integration tests to be Client parameterized
[ https://issues.apache.org/jira/browse/TINKERPOP-878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-878: --- Fix Version/s: (was: 3.3.1) > Refactor Gremlin Server integration tests to be Client parameterized > > > Key: TINKERPOP-878 > URL: https://issues.apache.org/jira/browse/TINKERPOP-878 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.0.2-incubating >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > > Would be nice if Gremlin Server integration tests (at least the ones that > make sense anyway) were executed over both Websockets and NIO to generally > validate their capabilities. We could likely create parameterized tests to > do this. That would also pave the way for easily testing new transports if > they are ever added. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1770) Remote traversal timeout
[
https://issues.apache.org/jira/browse/TINKERPOP-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1770.
---
Resolution: Done
Fix Version/s: 3.3.1
3.2.7
> Remote traversal timeout
>
>
> Key: TINKERPOP-1770
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1770
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.2.7, 3.3.1
>
>
> Remote traversals do not respect {{scriptEvaluationTimeout}} so it is
> currently possible to submit a traversal that runs indefinitely.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
[
https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164753#comment-16164753
]
stephen mallette commented on TINKERPOP-1474:
-
> so is the goal for the Java GLV to have the Vertex class be removed of its
> Properties methods?
If we're talking about a distant future for TinkerPop 4.x then, yes, there will
only be reference vertices/edges. For now, in TinkerPop 3.x I think we've gone
too far down the path of enabling properties in Java to ever really take them
away. We can only hide them via TINKERPOP-1701 and encourage users to think
property-less. I think we just want to align 3.x with the idea of where things
are headed further in the future. So the discrepancy of properties will
basically remain between java and python, js, etc, but we will likely shift
defaults over time to not include properties for Java (with java users having
the option to go back to including properties if they like as a method of
backward compatibility).
> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave
> some question about what *should* be returned from a simple traversal like
> `g.V()`.
> The java implementation presently assumes that properties could be present
> and returns a DetachedVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more
> reminiscent of a ReferenceVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align
> these APIs?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TINKERPOP-1779) Bump to GMavenPlus 1.6
stephen mallette created TINKERPOP-1779:
---
Summary: Bump to GMavenPlus 1.6
Key: TINKERPOP-1779
URL: https://issues.apache.org/jira/browse/TINKERPOP-1779
Project: TinkerPop
Issue Type: Improvement
Components: build-release
Affects Versions: 3.2.6
Reporter: stephen mallette
Assignee: stephen mallette
Priority: Minor
The new version of GMavenPlus allows for a few new capabilities which we can
make use of. Most useful is the ability to specify a groovy file for the
{{execute}} goal. As we now make use of this goal in the GLVs pretty heavily we
could greatly clean up the poms and make better re-use of code if that stuff
could be pulled out into script files that could be referenced by any module
that needs it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TINKERPOP-1780) Add authentication tests for gremlin-python
stephen mallette created TINKERPOP-1780: --- Summary: Add authentication tests for gremlin-python Key: TINKERPOP-1780 URL: https://issues.apache.org/jira/browse/TINKERPOP-1780 Project: TinkerPop Issue Type: Improvement Components: language-variant Affects Versions: 3.2.6 Reporter: stephen mallette Priority: Minor Include integration tests for authentication in gremlin-python. There is a secure test server running with the tests on port 45941 so we should be all good to add a test or two to validate this operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1778) Deprecate timedInterrupt option for Gremlin Server script processing
stephen mallette created TINKERPOP-1778:
---
Summary: Deprecate timedInterrupt option for Gremlin Server script
processing
Key: TINKERPOP-1778
URL: https://issues.apache.org/jira/browse/TINKERPOP-1778
Project: TinkerPop
Issue Type: Improvement
Components: server
Affects Versions: 3.2.6
Reporter: stephen mallette
Assignee: stephen mallette
Priority: Minor
The {{timedInterrupt}} option is not terribly useful because it basically does
what the combination of the regular {{scriptEvaluationTimeout}} with the
{{enableThreadInterrupt}} does. In fact it sort of competes with it, which can
lead to some different error paths which mean the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.
[
https://issues.apache.org/jira/browse/TINKERPOP-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155636#comment-16155636
]
stephen mallette commented on TINKERPOP-1287:
-
[~twilmes] is there anything to do on this one. doesn't seem like streams were
hurting anything and i think dan submitted a PR a while back to make
{{intern()}} configurable (maybe it should have just been removed). anyway,
anything else to do here?
> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
> Attachments: g.V.out.out.count.svg, stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from
> TinkerGraph made it much faster. It would be good if we did the same thing
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[
https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1792:
Component/s: python
groovy
> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
> Issue Type: Bug
> Components: groovy, python
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
> Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}}
> selection when processing lambdas. Obviously it should be bound more clearly
> to the specific {{TraversalSource}} the caller requests. Another issue that
> isn't completely clear is that bindings passed from the client share the same
> namespace as {{TraversalSource}} bindings which means that if the
> {{TraversalSource}} is "g" then you couldn't write a traversal like:
> {{withSideEffect(“g”, “hello”)}}. That could be smarter as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[
https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1792.
---
Resolution: Fixed
Assignee: stephen mallette
Fix Version/s: 3.3.1
3.2.7
> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
> Issue Type: Bug
> Components: groovy, python
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Labels: deprecation
> Fix For: 3.2.7, 3.3.1
>
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}}
> selection when processing lambdas. Obviously it should be bound more clearly
> to the specific {{TraversalSource}} the caller requests. Another issue that
> isn't completely clear is that bindings passed from the client share the same
> namespace as {{TraversalSource}} bindings which means that if the
> {{TraversalSource}} is "g" then you couldn't write a traversal like:
> {{withSideEffect(“g”, “hello”)}}. That could be smarter as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1795) Getting Lambda comparator message for .profile() step
[
https://issues.apache.org/jira/browse/TINKERPOP-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1795:
Component/s: process
> Getting Lambda comparator message for .profile() step
> --
>
> Key: TINKERPOP-1795
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1795
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.6
>Reporter: Shaunak Das
>Priority: Minor
>
> Ran into this message when adding a .profile() step, even though Gremlin
> query does not have any lambda steps:
> {code}
> gremlin>
> g.V().has("Question","questionType","yes/no").in("has_question").order().by(inE("reviewed").values("rating").mean()).profile()
> The provided step contains a lambda comparator:
> OrderGlobalStep([[[VertexStep(IN,[reviewed],edge),
> PropertiesStep([rating],value), MeanGlobalStep@[~gremlin.profile]], incr]])
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[ https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1792: Summary: Random TraversalSource Selection in GremlinScriptEngine (was: Random TraversalSource selection ) > Random TraversalSource Selection in GremlinScriptEngine > --- > > Key: TINKERPOP-1792 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1792 > Project: TinkerPop > Issue Type: Bug >Reporter: stephen mallette > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[ https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1792: Priority: Critical (was: Major) > Random TraversalSource Selection in GremlinScriptEngine > --- > > Key: TINKERPOP-1792 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1792 > Project: TinkerPop > Issue Type: Bug >Reporter: stephen mallette >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1792) Random TraversalSource selection
stephen mallette created TINKERPOP-1792: --- Summary: Random TraversalSource selection Key: TINKERPOP-1792 URL: https://issues.apache.org/jira/browse/TINKERPOP-1792 Project: TinkerPop Issue Type: Bug Reporter: stephen mallette -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[ https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1792: Affects Version/s: 3.2.6 > Random TraversalSource Selection in GremlinScriptEngine > --- > > Key: TINKERPOP-1792 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1792 > Project: TinkerPop > Issue Type: Bug >Affects Versions: 3.2.6 >Reporter: stephen mallette >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[
https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1792:
Description: {{GremlinScriptEngine}} implementations make a random
{{TraversalSource}} selection when processing lambdas. Obviously it should be
bound more clearly to the specific {{TraversalSource}} the caller requests.
This likely means deprecating the
> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
> Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}}
> selection when processing lambdas. Obviously it should be bound more clearly
> to the specific {{TraversalSource}} the caller requests. This likely means
> deprecating the
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[
https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1792:
Labels: deprecation (was: )
> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
> Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}}
> selection when processing lambdas. Obviously it should be bound more clearly
> to the specific {{TraversalSource}} the caller requests. This likely means
> deprecating the
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1792) Random TraversalSource Selection in GremlinScriptEngine
[
https://issues.apache.org/jira/browse/TINKERPOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1792:
Description: {{GremlinScriptEngine}} implementations make a random
{{TraversalSource}} selection when processing lambdas. Obviously it should be
bound more clearly to the specific {{TraversalSource}} the caller requests.
Another issue that isn't completely clear is that bindings passed from the
client share the same namespace as {{TraversalSource}} bindings which means
that if the {{TraversalSource}} is "g" then you couldn't write a traversal
like: {{withSideEffect(“g”, “hello”)}}. That could be smarter as well. (was:
{{GremlinScriptEngine}} implementations make a random {{TraversalSource}}
selection when processing lambdas. Obviously it should be bound more clearly to
the specific {{TraversalSource}} the caller requests. This likely means
deprecating the )
> Random TraversalSource Selection in GremlinScriptEngine
> ---
>
> Key: TINKERPOP-1792
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1792
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Priority: Critical
> Labels: deprecation
>
> {{GremlinScriptEngine}} implementations make a random {{TraversalSource}}
> selection when processing lambdas. Obviously it should be bound more clearly
> to the specific {{TraversalSource}} the caller requests. Another issue that
> isn't completely clear is that bindings passed from the client share the same
> namespace as {{TraversalSource}} bindings which means that if the
> {{TraversalSource}} is "g" then you couldn't write a traversal like:
> {{withSideEffect(“g”, “hello”)}}. That could be smarter as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-942) Use EventStrategy to solve OLAP bulk mutation of OLTP.
[
https://issues.apache.org/jira/browse/TINKERPOP-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-942:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> Use EventStrategy to solve OLAP bulk mutation of OLTP.
> --
>
> Key: TINKERPOP-942
> URL: https://issues.apache.org/jira/browse/TINKERPOP-942
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7
>
>
> We need to be able to do this in TinkerPop3.
> https://github.com/thinkaurelius/faunus/wiki/Distributed-Graph-Computing-with-Gremlin
> This can be solved with {{EventStrategy}}.
> Lets think of the hardest problem first -- distributed graph database (e.g.
> Titan) being mutated by a distributed graph processor (e.g. Giraph). Each
> Giraph node will map to a Titan node. Then the Giraph node will create a
> connection back to the respective Titan node via the {{writeGraph}} model by
> [~dkuppitz] in {{BulkLoaderVertexProgram}}. Every time a {{addV()}},
> {{addE()}}, {{property()}} is called, an event is fired and THAT event is
> call back to the Titan to create the vertex/edge/property. Likewise for
> {{drop()}}, etc. In other words, all {{Mutating}} steps can have a call back
> in OLAP to mutate the OLTP system.
> What about the easy case of {{TInkerGraph}} OLAP talking to {{TinkerGraph}}
> OLTP? Well, this gets back to {{GraphComputer.RESULT_GRAPH}} and whether your
> graph computer is operating over the real graph or a clone of it. However, I
> think its just the same as TItan/Giraph-style.
> So what is this good for?
> * Drop all the "knows" edges.
> * Change all the date properties from {{java.util.Date}} to {{Long}}.
> * Infer all {{foaf}}-edges.
> * etc.
> Things to consider -- transactions.
> If we solve this cleanly, then that is truly the final "big hurdle" in the
> {{GraphComputer}} story.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1070) Enable edge mutations in GraphComputer
[
https://issues.apache.org/jira/browse/TINKERPOP-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1070:
Fix Version/s: (was: 3.2.6)
3.2.7
> Enable edge mutations in GraphComputer
> --
>
> Key: TINKERPOP-1070
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1070
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> Right now you can only mutate vertex properties. You CAN NOT add/delete
> vertices nor add/delete edges. At least, there is no specification for the
> semantics of this and thus, there is no consistent behavior between different
> providers. This might be easy --- or it might be hard :).
> Make this work for TinkerGraph, Spark, and Giraph and then create test cases
> for the semantics in {{GraphComputerTest}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-963) SubgraphTraversalAnalyzer to determine what is really required from a traversal.
[
https://issues.apache.org/jira/browse/TINKERPOP-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-963:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> SubgraphTraversalAnalyzer to determine what is really required from a
> traversal.
>
>
> Key: TINKERPOP-963
> URL: https://issues.apache.org/jira/browse/TINKERPOP-963
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> This idea is dependent on the work in TINKERPOP3-962 being complete.
> The idea is that there should be a {{SubgraphTraversalAnalyzer}}-type step
> that for a {{traversal}} returns a
> {{Pair,Traversal>}} that defines two
> "filters" that contain the subgraph that the traversal will execute in.
> For instance.
> {code}
> g.V().hasLabel("person").out("pets").hasLabel("dog")
> {code}
> {{SubgraphTraversalAnalyzer}} would return
> {code}
> Pair.with(
> hasLabel("person","dog"),
> hasLabel("pets"))
> {code}
> The difficulty with this ticket is that TinkerPop does NOT make any
> assumptions about a schema. For instance, if the user did this:
> {code}
> g.V().hasLabel("person").out("pets")
> {code}
> Then the best we could return is:
> {code}
> Pair.with(
> identity(),
> hasLabel("pets"))
> {code}
> cc/ [~mbroecheler]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-831) How should OLAP treat Collection objects? No contract is specified.
[
https://issues.apache.org/jira/browse/TINKERPOP-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-831:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> How should OLAP treat Collection objects? No contract is specified.
>
>
> Key: TINKERPOP-831
> URL: https://issues.apache.org/jira/browse/TINKERPOP-831
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.7
>
>
> Assume the following OLAP query:
> {code}
> g.V.group.by(label).by().by(order(local).by('name'))
> {code}
> The {{Map}} that is processed by {{GroupMapReduce}}
> doesn't have "real vertices." For TinkerGraph/Spark/Giraph, we use
> {{DetachedVertices}}. However, we don't have a specification for forcing this
> on vendors. We need a contract so its not "who knows?! -- pura vida
> -- namaste -- comme ci, comme ça"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-620) Commutative Step Marker interface
[ https://issues.apache.org/jira/browse/TINKERPOP-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-620: --- Fix Version/s: (was: 3.2.6) 3.2.7 > Commutative Step Marker interface > - > > Key: TINKERPOP-620 > URL: https://issues.apache.org/jira/browse/TINKERPOP-620 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Matthias Broecheler > Fix For: 3.2.7 > > > Some steps can be reordered, i.e. they are commutative. For instance, > has-steps can be reordered without affecting the pipeline. When writing a > query optimizer I am often in a situation where I can only optimize a subset > of the supported steps and I might want to reorder them so that I can group > all the optimizable steps together. Currently, I have to manually identify > the commutative steps for that. It would be much nicer if TinkerPop could > have a "Commutative" marker interface for that and use it consistently. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1129) Make StarGraphGraphSONSerializer and connect it up with GraphFilter and GraphSONInputFormat
[
https://issues.apache.org/jira/browse/TINKERPOP-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1129:
Fix Version/s: (was: 3.2.6)
3.2.7
> Make StarGraphGraphSONSerializer and connect it up with GraphFilter and
> GraphSONInputFormat
> ---
>
> Key: TINKERPOP-1129
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1129
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop, io
>Affects Versions: 3.2.5
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> Currently, only {{ScriptInputFormat}} and {{GryoInputFormat}} are able to
> leverage {{GraphFilter}} "close to the metal." We should do the same for
> {{GraphSONInputFormat}} via {{StarGraphGraphSONSerializer}}. It shouldn't be
> that hard, just need to do it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1692) Bump to Neo4j 3.0.3
[ https://issues.apache.org/jira/browse/TINKERPOP-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1692: Fix Version/s: (was: 3.3.0) 3.3.1 > Bump to Neo4j 3.0.3 > --- > > Key: TINKERPOP-1692 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1692 > Project: TinkerPop > Issue Type: Improvement > Components: neo4j >Affects Versions: 3.2.5 >Reporter: stephen mallette > Fix For: 3.3.1 > > > There is a newer version of Neo4j available - > https://mvnrepository.com/artifact/org.neo4j/neo4j-tinkerpop-api-impl/0.4-3.0.3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1515) One test suite to rule them all
[ https://issues.apache.org/jira/browse/TINKERPOP-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1515: Fix Version/s: (was: 3.3.0) 3.3.1 > One test suite to rule them all > --- > > Key: TINKERPOP-1515 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1515 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: stephen mallette > Labels: breaking > Fix For: 3.3.1 > > > Make an attempt at an uber test module that would collapse all provider > related tests into a single module. I say "attempt" as I'm not completely > aware of what kinds of dependency conflicts I'll see try to do this. > Consider TINKERPOP-1410 in doing this. > Obviously this change would be breaking if modules are combined and package > renaming occurs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1326) Use KryoShim for serialization in VertexProgramHelper
[
https://issues.apache.org/jira/browse/TINKERPOP-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1326:
Fix Version/s: (was: 3.3.0)
3.3.1
> Use KryoShim for serialization in VertexProgramHelper
> -
>
> Key: TINKERPOP-1326
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1326
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process, structure
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.3.1
>
>
> At the next major release, we should swap out the Java serialization work in
> {{VertexProgramHelper}} and instead, use the {{KryoShim}} work developed by
> [~dalaro]. This means we need a {{KryoShimService}} in {{gremlin-core}}. I
> say we remove the {{HadoopPoolsKryoShimService}} and go with a
> {{GryoPoolKryoShimService}} that then Hadoop-based OLAP engines can use (as
> well as engines like TinkerGraph).
> This would a a "minor breaking" change as I suspect no provider is that deep
> into the serialization API of TinkerPop and the change would be a simple
> "change X to Y" sort of change for them.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-878) Refactor Gremlin Server integration tests to be Client parameterized
[ https://issues.apache.org/jira/browse/TINKERPOP-878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-878: --- Fix Version/s: (was: 3.3.0) 3.3.1 > Refactor Gremlin Server integration tests to be Client parameterized > > > Key: TINKERPOP-878 > URL: https://issues.apache.org/jira/browse/TINKERPOP-878 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.0.2-incubating >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Fix For: 3.3.1 > > > Would be nice if Gremlin Server integration tests (at least the ones that > make sense anyway) were executed over both Websockets and NIO to generally > validate their capabilities. We could likely create parameterized tests to > do this. That would also pave the way for easily testing new transports if > they are ever added. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1344) ReferenceYYYXXX for better message passing
[
https://issues.apache.org/jira/browse/TINKERPOP-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1344:
Fix Version/s: (was: 3.3.0)
3.3.1
> ReferenceYYYXXX for better message passing
> --
>
> Key: TINKERPOP-1344
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1344
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.3.1
>
>
> In https://issues.apache.org/jira/browse/TINKERPOP-1343, I was saying that it
> would be nice to have the element id type be known so we can do
> {{writeObject()}} as opposed to {{writeObjectAndClass()}}. I think we could
> do some good with a hiearchy of classes like:
> {code}
> ReferenceIntVertex
> ReferenceLongVertex
> ReferenceVertex (Object -- what we have now)
> ReferenceUUIDVertex
> ...
> {code}
> ...likewise for Edge, VertexProperty...
> This will save us an extra 32-bits (4 byte int) on the serialization of
> messages during OLAP message pass as that is all {{ReferenceXXX}} based.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1717) Update name and link of DynamoDB storage backend in landing page
[ https://issues.apache.org/jira/browse/TINKERPOP-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1717: Fix Version/s: (was: 3.3.0) 3.3.1 > Update name and link of DynamoDB storage backend in landing page > > > Key: TINKERPOP-1717 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1717 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.2.3 >Reporter: Alexander Patrikalakis >Priority: Minor > Fix For: 3.3.1 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Amazon have released DynamoDB storage backends compatible with JG 0.1.0 and > 0.1.1: > https://mvnrepository.com/artifact/com.amazonaws/dynamodb-janusgraph-storage-backend/1.0.0 > https://mvnrepository.com/artifact/com.amazonaws/dynamodb-janusgraph-storage-backend/1.1.0 > Also, we have renamed the repository on GitHub to > dynamodb-janusgraph-storage-backend for git history continuity. So, can we > update the names and links on the landing page? Also minor, I would like to > update the capitalization of "storage backend" -> "Storage Backend" > Before: > [Titan (Amazon)](https://github.com/awslabs/dynamodb-titan-storage-backend/) > - The Amazon DynamoDB storage backend for Titan. > After: > [JanusGraph > (Amazon)](https://github.com/awslabs/dynamodb-janusgraph-storage-backend/) - > The Amazon DynamoDB Storage Backend for JanusGraph. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1346) Create custom ReferenceXXX GryoSerializers
[
https://issues.apache.org/jira/browse/TINKERPOP-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1346:
Fix Version/s: (was: 3.3.0)
3.3.1
> Create custom ReferenceXXX GryoSerializers
> --
>
> Key: TINKERPOP-1346
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1346
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, structure
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.3.1
>
>
> Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] +
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] +
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
> {code}
> Assuming {{Long}} Element ids, the math says:
> {code}
> 48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8
> bytes [long]) + 4 bytes + (4 bytes + 8 bytes [long])
> {code}
> We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] +
> KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
> {code}
> The math says:
> {code}
> 36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] +
> 8 bytes [long]
> {code}
> Similar techniques would apply to {{ReferenceVertexProperty}} and
> {{ReferenceProperty}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1403) Provide support for GraphFilter.vertexProperties()
[
https://issues.apache.org/jira/browse/TINKERPOP-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1403:
Fix Version/s: (was: 3.3.0)
3.3.1
> Provide support for GraphFilter.vertexProperties()
> --
>
> Key: TINKERPOP-1403
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1403
> Project: TinkerPop
> Issue Type: Improvement
> Components: process, structure
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.3.1
>
>
> [~rspitzer] stated that he is working with a graph that has millions of
> vertex properties on a vertex. If those properties are not needed for the
> traversal, then they should be filtered out.
> Much like {{GraphFilter.edges()}}, we should add
> {{GraphFilter.vertexProperties(Traversal)}}. That is,
> from the {{Vertex}} in question, traverse to those properties needed in the
> computation, where {{properties().limit(0)}} would be the push down predicate
> for "no properties." Another example, {{properties("income")}} would only
> provide income properties. Another example,
> {{properties("income").has("acl","public")}} would provide only those income
> properties that are public (according to access control).
> --- SIDENOTE. In the docs we have {{bothE().limit(0)}} as the predicate for
> no edges. However, {{limit(0)}} by itself is sufficient. Likewise for
> {{GraphFilter.vertexProperties()}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1535) Bump to support Giraph 1.2.0.
[ https://issues.apache.org/jira/browse/TINKERPOP-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1535: Fix Version/s: (was: 3.3.0) 3.3.1 > Bump to support Giraph 1.2.0. > - > > Key: TINKERPOP-1535 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1535 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop >Affects Versions: 3.2.3 >Reporter: Marko A. Rodriguez >Assignee: Marko A. Rodriguez > Fix For: 3.3.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1128) Change the Gryo serialization for StarGraph (Vertex, Properties, then Edges)
[
https://issues.apache.org/jira/browse/TINKERPOP-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1128:
Fix Version/s: (was: 3.3.0)
3.3.1
> Change the Gryo serialization for StarGraph (Vertex, Properties, then Edges)
>
>
> Key: TINKERPOP-1128
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1128
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.3.1
>
>
> Right now we serialize first the vertex, then its edges, then its properties.
> We should do vertex, properties, edges. Why? If we know that the vertex is to
> be filtered (which is an analysis of its label/id/properties), then we can
> skip over analyzing its edges. Right now, we may do all this work
> deserializing edges only to realize that the {{GraphFilter}} says that the
> vertex is filtered. Dah, pointless clock cycles -- especially when edge sets
> can be massive.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-871) RuntimeStrategy as the general model for all such execution time rewrites/re-orders
[
https://issues.apache.org/jira/browse/TINKERPOP-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-871:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> RuntimeStrategy as the general model for all such execution time
> rewrites/re-orders
> ---
>
> Key: TINKERPOP-871
> URL: https://issues.apache.org/jira/browse/TINKERPOP-871
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.7
>
>
> {{TraversalStrategies}} are used at compile time to translate a traversal
> into a more optimal, graph system specific, or decorated traversal. These all
> execute at compile time. However, we also have {{MatchAlgorithm}} which is
> used by {{MatchStep}} to do runtime analysis and resort patterns accordingly.
> I would like to make {{MatchAlgorithm}} implement {{RuntimeStrategy}} and
> start to build out a collection of {{RuntimeStrategies}}. Where else could we
> leverage runtime analysis:
> * {{OrStep}} and {{AndStep}} -- which pattern is filtering fastest? Do that
> first.
> * {{MatchStep}} -- already using it with {{CountMatchAlgorithm}} and pattern
> sorting.
> * ???
> ... can't think, there are probably more.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-819) Mapping Cardinality Interface
[
https://issues.apache.org/jira/browse/TINKERPOP-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-819:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> Mapping Cardinality Interface
> -
>
> Key: TINKERPOP-819
> URL: https://issues.apache.org/jira/browse/TINKERPOP-819
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Labels: breaking
> Fix For: 3.2.7
>
>
> I think it would be handy (for some {{sack()}} work I'm doing on
> merging/splitting sacks), but also in general as I've wanted this before
> (can't remember why). I think we should add the following interfaces.
> {code}
> ManyToOneMapping (e.g. reducing barriers)
> OneToManyMapping (e.g. flatmap)
> OneToOneMapping (e.g. map, sideeffects)
> OneToOneOrNoneMapping (e.g. filter)
> {code}
> We can just rely on {{instanceof FlatMapStep}} or {{instanceof MapStep}} as
> there are steps that are "map steps" but don't extend {{MapStep}}, but
> instead {{AbstractStep}}. Either we make it so that all steps MUST extend
> from {{FlatMapStep}}, {{MapStep}}, etc. or we can add the above interfaces.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1074) More contractual testing/specifications around Persist and ResultGraph.
[
https://issues.apache.org/jira/browse/TINKERPOP-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1074:
Fix Version/s: (was: 3.2.6)
3.2.7
> More contractual testing/specifications around Persist and ResultGraph.
> ---
>
> Key: TINKERPOP-1074
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1074
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> A {{ComputerResult}} references two objects: a graph and a memory. The graph
> is the resultant computed graph and the memory contains all the sideEffect
> data from the computation (if any).
> Right now, we have the following {{Persist}} options: {{NOTHING}},
> {{VERTEX_PROPERTIES}}, {{EDGES}}. We also have the following {{ResultGraph}}
> options: {{ORIGINAL}}, {{NEW}}.
> * NOTHING + ORIGINAL = ComputerResult contains original graph reference.
> * NOTHING + NEW = ?? No test to force what this means! Should be
> {{EmptyGraph.instance()}}.
> * VERTEX_PROPERTIES + ORIGINAL = ComputerResult contains original graph, but
> the computed vertex properties have been "saved" to it. (no contractual test
> cases here either!)
> * VERTEX_PROPERTIES + NEW = ComputerResult contains new graph with only
> vertices and their properties.
> * EDGES + NEW = ComputerResult contains new graph with vertices, edges, and
> their properties.
> * EDGES + ORIGINAL = ComputerResult contains original graph, but the computed
> vertex properties and edges have been "saved" to it. (no contractual test
> cases here either!)
> {{TinkerGraphComputer}} is the only system that supports all the above
> configuration combinations. Add test cases to {{GraphComputerTest}} that
> verify the behavior of all combinations.
> HOWEVER -- should we really respect ORIGINAL+PERSIST? Most providers
> will use {{BulkLoaderVertexProgram}} to write the computed graph back to the
> original graph. If there are TWO ways of doing this, this seems bad? In fact,
> the way that TinkerGraphComputer writes the computed graph back to the
> original graph is nearly identical to how it BulkLoaderVertexProgram works.
> Thus, I'm wondering if we simply get rid the concept of {{ResultGraph}} and
> ONLY have {{Persist}}.
> * Persist.NOTHING: Returns the original graph in {{ComputerResult}}.
> * Persist.VERTEX_PROPERTIES: Returns a new graph with only vertices and
> properties.
> * Persist.EDGES: Returns a new graph with vertices, edges, and their
> properties.
> For in-memory graphs like {{TinkerGraph}}, "new graph" can mean the original
> graph with the {{GraphView}} overlay. Thus, its not really a full copy of the
> original graph. Moreover, Persist.NOTHING just garbage collects the GraphView
> and thus, the original graph.
> --
> Next, what does {{Persist}} mean for memory? Remember, {{ComputerResult}}
> also has a reference to sideEffect memory. What if you want to run a job, NOT
> persist the graph, but persist the memory only. I think we should ALWAYS
> assume memory persistence. For TinkerGraph, that means the the
> ComputerResult.memory() has a HashMap of memory values. For Giraph/Spark,
> that means that the {{Storage}} will always have resultant sideEffect data in
> the output directory even if there is no graph.
> * {{NOTHING}}: persist memory and return the original graph.
> * {{VERTEX_PROPERTIES}}: persist memory and return new graph of just vertex
> properties.
> * {{EDGES}}: persist memory and return new graph of vertex properties, and
> edges.
> Decisions, decisions, decisions
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-966) Support reversible traversals in MatchStep (and respective MatchAlgorithms)
[
https://issues.apache.org/jira/browse/TINKERPOP-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-966:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> Support reversible traversals in MatchStep (and respective MatchAlgorithms)
> ---
>
> Key: TINKERPOP-966
> URL: https://issues.apache.org/jira/browse/TINKERPOP-966
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> We currently do not support the reversing of a traversal. Thus,
> {code}
> g.V().match(
> as("a").out("knows").as("b")
> as("c").out("knows").as("a"))
> {code}
> will throw an exception saying that it can't compute the patterns. If we can
> convert {{as("c").out("knows").as("a")}} to {{as("a").in("knows").as("c")}}
> then this will work. Furthermore, we need a way to have two versions of a
> traversal pattern available. For instance:
> {code}
> g.V().match(
> as("a").out("knows").as("b")
> as("a").out("friend").as("b"))
> {code}
> Given the above patterns, it is possible for both patterns to have a standard
> and a "reversed-form" that can be selected dynamically given the
> match-path-history and pattern statistics. Thus, we need a way to have all
> four patterns able to be selected but once one of the two-pair is selected
> for a traverser, it can't use the other.
> In short, we need {{TraversalHelper.reverse(Traversal)}} and
> {{MathStep.MatchAlgorithm}} book-keeping data structures.
> cc/ [~mbroecheler]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1187) Create a GraphComputer Tutorial
[ https://issues.apache.org/jira/browse/TINKERPOP-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1187: Fix Version/s: (was: 3.2.6) 3.2.7 > Create a GraphComputer Tutorial > --- > > Key: TINKERPOP-1187 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1187 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.1.1-incubating >Reporter: Marko A. Rodriguez >Assignee: Marko A. Rodriguez > Fix For: 3.2.7 > > > We should create a GraphComputer tutorial that discusses: > 1. GraphComputer, Memory, and VertexPrograms. > 2. Explains how Traversals are compiled to TraversalVertexPrograms. > 3. The mechanics of a TraversalVertexProgram. > 4. How to write your own VertexProgram. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.
[
https://issues.apache.org/jira/browse/TINKERPOP-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1287:
Fix Version/s: (was: 3.2.6)
3.2.7
> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
> Attachments: g.V.out.out.count.svg, stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from
> TinkerGraph made it much faster. It would be good if we did the same thing
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1141) HadoopRemoteAcceptor is overly complicated. Simplify with ComputerResult as a SideEffect in OLAP Traversal.
[
https://issues.apache.org/jira/browse/TINKERPOP-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1141:
Fix Version/s: (was: 3.2.6)
3.2.7
> HadoopRemoteAcceptor is overly complicated. Simplify with ComputerResult as a
> SideEffect in OLAP Traversal.
> ---
>
> Key: TINKERPOP-1141
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1141
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop, process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> {{HadoopRemoteAcceptor}} is overly complicated. I think that instead of
> making {{ComputerResult}} a value in the Console, we should just add
> {{ComputerResult}} to the OLAP {{Traversal}}.
> {code}
> t = g.V().out().count()
> result = t.getSideEffects().get('~computerResult')
> {code}
> For most people, they will never use this as computer result memory is
> already in the sideEffects. However, {{ComputerResult}} also has other
> information like iteration, runtime, and graph.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-882) Develop a less error prone way for rewriting strategies
[
https://issues.apache.org/jira/browse/TINKERPOP-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-882:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> Develop a less error prone way for rewriting strategies
> ---
>
> Key: TINKERPOP-882
> URL: https://issues.apache.org/jira/browse/TINKERPOP-882
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> When someone writes a {{TraversalStrategy}} it is of the nature:
> {code}
> if(step instanceof SelectStep && ((SelectStep)step).getLocalChildren().size()
> > 1) {
> TraversalHelper.insertStep(new IdentityStep(), step, traversal);
> }
> {code}
> It can start to get hairy looking fast. It would be great if we could study
> the strategies we have thus far and see if there are patterns we can extract
> encapsulate such behaviors in new methods in {{TraversalHelper}}. I don't
> have any good ideas on how to do this, but I think we need it. My only
> thought was a "regular expression" language for our traversals so we can
> pattern match ON the traversal.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-669) Consider Required TraversalStrategies
[
https://issues.apache.org/jira/browse/TINKERPOP-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-669:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> Consider Required TraversalStrategies
> -
>
> Key: TINKERPOP-669
> URL: https://issues.apache.org/jira/browse/TINKERPOP-669
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.7
>
>
> As we now execute the Gremln process suite with and without strategies
> applied, it became apparent that some strategies are simply "required". See:
> https://github.com/apache/incubator-tinkerpop/blob/0d239c05638269e6cd5c7af7bd3c61a50627d0bc/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/TinkerGraphNoStrategyComputerProvider.java#L41-L46
> https://github.com/apache/incubator-tinkerpop/blob/0d239c05638269e6cd5c7af7bd3c61a50627d0bc/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/TinkerGraphNoStrategyProvider.java#L42
> Not sure what this means in the grand scheme of things. A few things that
> feel weird or require more thought:
> 1. Kinda weird that a {{Traversal}} requires any strategies at all to execute.
> 2. Kinda weird that a {{Step}} should know anything about strategies as is
> the case with {{ConjunctionStrategy}} for example.
> 3. If required strategies are expected then should those required strategies
> be somewhere more prominently maintained/documented/etc than just being
> relegated to the test suite
> Not sure anything really needs to change here, just wanted to create an issue
> for future thought.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1687) Record metrics around how long it gremlin script executions sit in executor queue waiting to be executed.
[ https://issues.apache.org/jira/browse/TINKERPOP-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1687: Fix Version/s: (was: 3.2.6) 3.2.7 > Record metrics around how long it gremlin script executions sit in executor > queue waiting to be executed. > - > > Key: TINKERPOP-1687 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1687 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.4 >Reporter: David Pitera >Priority: Minor > Labels: breaking > Fix For: 3.2.7 > > > The issue will be breaking because I will be moving the MetricManager into > the gremlin-core project from the gremlin-server project for easier use > across the project. Therefore whoever is using the MetricManager will need to > update their location from where they grab it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-889) Support for partitioned vertices in GraphComputer
[ https://issues.apache.org/jira/browse/TINKERPOP-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-889: --- Fix Version/s: (was: 3.2.6) 3.2.7 > Support for partitioned vertices in GraphComputer > - > > Key: TINKERPOP-889 > URL: https://issues.apache.org/jira/browse/TINKERPOP-889 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Matthias Broecheler >Assignee: Marko A. Rodriguez > Labels: breaking > Fix For: 3.2.7 > > > Most natural graphs have scale free distributions which means that some > vertices in the graph have significantly more incident edges than others. On > large graphs, it is therefore not uncommon to encounter vertices whose > adjacency list is to large to be accommodated efficiently by a single machine > (due to lack of sufficient memory or because they create a hotspot). > Other graph computing frameworks have successfully addressed this "supernode > problem" by partitioning the vertex's adjacency list and processing each > subset of the adjacency list separately because merging the results (e.g. > counting edges in each subset and then adding those values to get the total > degree). TinkerPop should implement such functionality and allow partitioned > vertex adjacency lists in the input to GraphComputer. This is a critical > feature to make TP applicable to large graph computations. > This can be implemented fairly easily for local messages using the message > combiners. Global messages can be tricky however. See also TINKERPOP3-383. > This has been partially implemented in Titan's Fulgora package > (https://github.com/thinkaurelius/titan/tree/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/olap). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-940) Convert LocalTraversals to MatchSteps in OLAP and Solve the StarGraph Problem
[
https://issues.apache.org/jira/browse/TINKERPOP-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-940:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> Convert LocalTraversals to MatchSteps in OLAP and Solve the StarGraph Problem
> -
>
> Key: TINKERPOP-940
> URL: https://issues.apache.org/jira/browse/TINKERPOP-940
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> This fails in OLAP.
> {code}
> g.V().match(
> as('a').out('sungBy').as('b'),
> as('a').out('writtenBy').as('b')).
> select('a','b').by('name')
> {code}
> However, this passes:
> {code}
> g.V().match(
> as('a').out('sungBy').as('b'),
> as('a').out('writtenBy').as('b'),
> as('a').values('name').as('c'),
> as('b').values('name').as('d')).
> select('c','d')
> {code}
> Can all "local star graph" OLAP problems be strategized into MatchSteps? It
> would be a decoration strategy of some sort [~dkuppitz]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1098) Local Filters
[
https://issues.apache.org/jira/browse/TINKERPOP-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1098:
Fix Version/s: (was: 3.2.6)
3.2.7
> Local Filters
> -
>
> Key: TINKERPOP-1098
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1098
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Daniel Kuppitz
> Fix For: 3.2.7
>
>
> We should provide local filter steps. Currently, if you want to filter
> elements from paths or lists (or maps?), you have to do
> {{unfold().filter().fold()}}.
> Not sure if that only affects {{filter()}}, or also {{has()}}, {{hasNot()}},
> {{where()}}, ...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-743) Support "barrier syntax" in step labels.
[
https://issues.apache.org/jira/browse/TINKERPOP-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-743:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> Support "barrier syntax" in step labels.
>
>
> Key: TINKERPOP-743
> URL: https://issues.apache.org/jira/browse/TINKERPOP-743
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Labels: breaking
> Fix For: 3.2.7
>
>
> Here is a basic recommendation algorithm that we currently can not do in
> match().
> {code}
> g.V(1).as('a').out('likes').aggregate('x'). // what does v[1] like
> in('likes').where(neq('a')).// who else likes those things
> that are not v[1]
> out('likes').where(not(within('x')).// what do those people like that
> v[1] doesn't already like
> groupCount()// count the number of times each
> liked thing is seen
> {code}
> Why can't we do this in match()? Because we can not aggregate (well, we can,
> but bare with me). The best we can do is:
> {code}
> g.V(1).match('a',
> as('a').out('likes').as('b'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',neq('b')),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> So what's the problem? The problem is that where('d',neq('b')) is only going
> to make sure that the current 'd' is not equal to the current 'b'. Not the
> aggregate of all b's. How do we solve this? Here is how we would "manually"
> solve it using Kuppitz' latest idea of adding a clear()-step, where
> clear('x') => sideEffect{it.sideEffects('x').clear()}
> {code}
> g.V(1).match('a',
> as('a').clear('{b}').out('likes').aggregate('{b}').as('b'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',not(within('{b}'))),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> However, suppose that we make "{ }" (set) and "[ ]" (list) special label
> characters whereby the above is compiled to from the following:
> {code}
> g.V(1).match('a',
> as('a').out('likes').as('{b}'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',not(within('{b}'))),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> In essence, if an end variable is labeled with "{ }" that means aggregate to
> set ("[ ]" could mean aggregate to list). The variable name inside the "{ }"
> is then the "drain" of the CollectingBarrierStep -- i.e., the single object
> emission post aggregation. Next, the as("{b}") syntax need not be limited to
> match() where, in fact, the first query of this email could be written as:
> {code}
> g.V(1).as('a').out('likes').as('{x}').
> in('likes').where(neq('a')).
> out('likes').where(not(within('{x}')).
> groupCount()
> {code}
> Where does the clear() go in the above? It goes after the first StartStep
> encountered moving "left." Thus, the previous compiles to the following:
> {code}
> g.V(1).as('a').clear('{x}').out('likes').aggregate('{x}').as('x')
> in('likes').where(neq('a')).
> out('likes').where(not(within('{x}')).
> groupCount()
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1711) map(union(fold())) bug
[
https://issues.apache.org/jira/browse/TINKERPOP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1711:
Fix Version/s: (was: 3.2.6)
3.2.7
> map(union(fold())) bug
> --
>
> Key: TINKERPOP-1711
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1711
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.5
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7
>
>
> Actual:
> {code:java}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().valueMap()
> ==>[name:[marko],age:[29]]
> ==>[name:[vadas],age:[27]]
> ==>[name:[lop],lang:[java]]
> ==>[name:[josh],age:[32]]
> ==>[name:[ripple],lang:[java]]
> ==>[name:[peter],age:[35]]
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[[],vadas]
> ==>[lop,[java]]
> ==>[[],josh]
> ==>[ripple,[java]]
> ==>[[],peter]
> {code}
> Expected:
> {code:java}
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[vadas,[]]
> ==>[lop,[java]]
> ==>[josh,[]]
> ==>[ripple,[java]]
> ==>[peter,[]]
> {code}
> List reference:
> https://groups.google.com/forum/#!topic/gremlin-users/L_fESS6ta0A
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-967) Support nested-repeat() structures
[
https://issues.apache.org/jira/browse/TINKERPOP-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-967:
---
Fix Version/s: (was: 3.2.6)
3.2.7
> Support nested-repeat() structures
> --
>
> Key: TINKERPOP-967
> URL: https://issues.apache.org/jira/browse/TINKERPOP-967
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> All the internal plumbing is staged for this to happen, we just haven't gone
> all the way. In short, a {{NESTED_LOOP}} traverser has an internal
> {{loopStack}} where {{repeat(repeat())}} will have a {{loopStack}} of two.
> The {{it.loops()}} checks of the internal repeat will always check the top of
> the stack and when its done repeating will delete its counter off the top of
> the stack.
> [~dkuppitz]'s work on {{LoopStep}} will be backwards compatible. In
> {{RepeatStep}} we will support:
> {code}
> repeat('a',out('knows').repeat('b',out('parent')))
> {code}
> and thus, things like {{loops('a')}} as well as {{times('a',2)}}. Note that
> naming the loop stack will be a super rare case as most people will just
> assume standard nested looping semantics with a push/pop stack.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1566) Kerberos authentication for gremlin-server
[ https://issues.apache.org/jira/browse/TINKERPOP-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1566: - > Kerberos authentication for gremlin-server > -- > > Key: TINKERPOP-1566 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1566 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Marc de Lignie >Assignee: stephen mallette >Priority: Minor > Labels: security > Fix For: 3.3.0 > > > Gremlin server would benefit from an explicit Kerberos authentication plugin, > because preparing and maintaining such a plugin is nontrivial. Also, many > other Apache project provide kerberized services. > In gremlin-console the standard Krb5LoginModule can be configured. > Gremlin-server already includes the pluggable Sasl framework that can host > the proposed Kerberos authentication plugin. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (TINKERPOP-1404) Path/label optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reopened TINKERPOP-1404:
-
> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r,
> step)}} is called there is no need to call {{Traverser.addLabels}} again in
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}}
> the step's labels can be used directly in the traverser. There is no need to
> make a copy of it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1404) Path/label optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1404.
---
Resolution: Fixed
> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r,
> step)}} is called there is no need to call {{Traverser.addLabels}} again in
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}}
> the step's labels can be used directly in the traverser. There is no need to
> make a copy of it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1404) Path/label optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1404:
Labels: (was: performance)
> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r,
> step)}} is called there is no need to call {{Traverser.addLabels}} again in
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}}
> the step's labels can be used directly in the traverser. There is no need to
> make a copy of it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
