[GitHub] tinkerpop issue #397: TINKERPOP-1389 Support Spark 2.0
Github user yucx commented on the issue: https://github.com/apache/tinkerpop/pull/397 Looks like there is performance issue, I will continue investigate it. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1389) Support Spark 2.0.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15457916#comment-15457916 ] ASF GitHub Bot commented on TINKERPOP-1389: --- Github user yucx commented on the issue: https://github.com/apache/tinkerpop/pull/397 Looks like there is performance issue, I will continue investigate it. > Support Spark 2.0.0 > --- > > Key: TINKERPOP-1389 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1389 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop >Affects Versions: 3.2.1 >Reporter: Chen Xin Yu > Fix For: 3.3.0 > > Attachments: TINKERPOP-1389.patch > > > Spark 2.0.0 was released: > http://spark.apache.org/news/spark-2-0-0-released.html > There are lots of improvement and changes compared to 1.6.1, we should better > bump to it for TinkerPop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop pull request #398: TINKERPOP-1426, GryoSerializer should implement...
GitHub user yucx opened a pull request: https://github.com/apache/tinkerpop/pull/398 TINKERPOP-1426, GryoSerializer should implement Java serialization in⦠GryoSerializer should implement Java serialization. Details in: https://issues.apache.org/jira/browse/TINKERPOP-1426 You can merge this pull request into a Git repository by running: $ git pull https://github.com/yucx/tinkerpop TINKERPOP-1426 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/398.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #398 commit 28b686841f00201617a1a6fdf38b2ee90e5c8a44 Author: yucx Date: 2016-09-02T09:00:41Z TINKERPOP-1426, GryoSerializer should implement Java serialization interface --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1426) GryoSerializer should implement Java serialization interface
[ https://issues.apache.org/jira/browse/TINKERPOP-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15458185#comment-15458185 ] ASF GitHub Bot commented on TINKERPOP-1426: --- GitHub user yucx opened a pull request: https://github.com/apache/tinkerpop/pull/398 TINKERPOP-1426, GryoSerializer should implement Java serialization in… GryoSerializer should implement Java serialization. Details in: https://issues.apache.org/jira/browse/TINKERPOP-1426 You can merge this pull request into a Git repository by running: $ git pull https://github.com/yucx/tinkerpop TINKERPOP-1426 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/398.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #398 commit 28b686841f00201617a1a6fdf38b2ee90e5c8a44 Author: yucx Date: 2016-09-02T09:00:41Z TINKERPOP-1426, GryoSerializer should implement Java serialization interface > GryoSerializer should implement Java serialization interface > > > Key: TINKERPOP-1426 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1426 > Project: TinkerPop > Issue Type: Bug > Components: io >Affects Versions: 3.2.1 >Reporter: Chen Xin Yu > > There is description for Serializer in spark: > * Implementations of this trait should implement: > * > * 1. a zero-arg constructor or a constructor that accepts a > [[org.apache.spark.SparkConf]] > * as parameter. If both constructors are defined, the latter takes > precedence. > * > * 2. Java serialization interface. > Class GryoSerializer in Tinkerepop extends Serializer, but does not implement > java.io.Serializable. > It works well before Spark 2.0. But with Spark 2.0, it changed by SPARK-13926 > for Dependency,scala. > Gyro and all its fields must implement Java serialisation interface, > otherwise hundreds of test cases are failed as: > Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: > Task not serializable: java.io.NotSerializableException: > org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer > Serialization stack: > - object not serializable (class: > org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer, value: > org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer@1b12ec8e) > - field (class: org.apache.spark.ShuffleDependency, name: serializer, > type: class org.apache.spark.serializer.Serializer) > - object (class org.apache.spark.ShuffleDependency, > org.apache.spark.ShuffleDependency@7a4f876a) > - field (class: scala.Tuple2, name: _2, type: class java.lang.Object) > - object (class scala.Tuple2, (MapPartitionsRDD[1] at mapToPair at > InputFormatRDD.java:46,org.apache.spark.ShuffleDependency@7a4f876a)) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1426) GryoSerializer should implement Java serialization interface
[ https://issues.apache.org/jira/browse/TINKERPOP-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15458260#comment-15458260 ] Chen Xin Yu commented on TINKERPOP-1426: There is performance issue with the two change sets together. This JIRA is not related to Spark 2.0, even without Spark 2.0, Class GryoSerializer should also implement Java serialization interface. So I submit a separate PR on github. https://github.com/apache/tinkerpop/pull/398 > GryoSerializer should implement Java serialization interface > > > Key: TINKERPOP-1426 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1426 > Project: TinkerPop > Issue Type: Bug > Components: io >Affects Versions: 3.2.1 >Reporter: Chen Xin Yu > > There is description for Serializer in spark: > * Implementations of this trait should implement: > * > * 1. a zero-arg constructor or a constructor that accepts a > [[org.apache.spark.SparkConf]] > * as parameter. If both constructors are defined, the latter takes > precedence. > * > * 2. Java serialization interface. > Class GryoSerializer in Tinkerepop extends Serializer, but does not implement > java.io.Serializable. > It works well before Spark 2.0. But with Spark 2.0, it changed by SPARK-13926 > for Dependency,scala. > Gyro and all its fields must implement Java serialisation interface, > otherwise hundreds of test cases are failed as: > Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: > Task not serializable: java.io.NotSerializableException: > org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer > Serialization stack: > - object not serializable (class: > org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer, value: > org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer@1b12ec8e) > - field (class: org.apache.spark.ShuffleDependency, name: serializer, > type: class org.apache.spark.serializer.Serializer) > - object (class org.apache.spark.ShuffleDependency, > org.apache.spark.ShuffleDependency@7a4f876a) > - field (class: scala.Tuple2, name: _2, type: class java.lang.Object) > - object (class scala.Tuple2, (MapPartitionsRDD[1] at mapToPair at > InputFormatRDD.java:46,org.apache.spark.ShuffleDependency@7a4f876a)) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1428) profile() throws NPE for union(group, group)
Daniel Kuppitz created TINKERPOP-1428:
-
Summary: profile() throws NPE for union(group, group)
Key: TINKERPOP-1428
URL: https://issues.apache.org/jira/browse/TINKERPOP-1428
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.2.1
Reporter: Daniel Kuppitz
{noformat}
gremlin> g.V().union(group("m").by("name"), group("m").by("name")).profile()
java.lang.NullPointerException
Type ':help' or ':h' for help.
Display stack trace? [yN]y
java.lang.NullPointerException
at
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:239)
at
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:251)
at
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.handleNestedTraversals(DefaultTraversalMetrics.java:254)
at
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalMetrics.setMetrics(DefaultTraversalMetrics.java:204)
at
org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.ProfileSideEffectStep.hasNext(ProfileSideEffectStep.java:73)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
at
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:179)
at
org.apache.tinkerpop.gremlin.console.Console$_closure3.doCall(Console.groovy:226)
at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1024)
at
org.codehaus.groovy.tools.shell.Groovysh.setLastResult(Groovysh.groovy:446)
at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:190)
at
org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
at
org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:72)
at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
at org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
at
org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
at
org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
at org.codehaus.groovy.tools.shell.ShellRunner.run(ShellRunner.groovy:59)
at
org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$run(InteractiveShellRunner.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.
[jira] [Updated] (TINKERPOP-1115) Improve GraphTraversal and GraphTraversalSource Reference Docs
[
https://issues.apache.org/jira/browse/TINKERPOP-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1115:
Description: We have the lambda representation of these steps, but not the
traversal representation such as {{map(traversal)}}, {{flatMap(traversal)}},
{{filter(traversal)}}, etc.. It would be futher good to cover the various
{{with...}} methods like {{withPath()}}, {{withSideEffect()}}, etc. (was: We
have the lambda representation of these steps, but not the traversal
representation.)
Summary: Improve GraphTraversal and GraphTraversalSource Reference Docs
(was: Add map(traversal), flatMap(traversal), filter(traversal), ?? to
Reference Docs)
Expanded the scope of this issue a little bit to cover the
{{GraphTraversalSource.with...()}} methods.
> Improve GraphTraversal and GraphTraversalSource Reference Docs
> --
>
> Key: TINKERPOP-1115
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1115
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> We have the lambda representation of these steps, but not the traversal
> representation such as {{map(traversal)}}, {{flatMap(traversal)}},
> {{filter(traversal)}}, etc.. It would be futher good to cover the various
> {{with...}} methods like {{withPath()}}, {{withSideEffect()}}, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-740) Serializer Handshake
[ https://issues.apache.org/jira/browse/TINKERPOP-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-740. -- Resolution: Won't Fix Fix Version/s: (was: 3.2.2) I sense that this issue won't be possible. Serializer configuration has gotten pretty deep and in some cases dynamic. It won't be possible to send that kind of stuff back in a handshake. > Serializer Handshake > > > Key: TINKERPOP-740 > URL: https://issues.apache.org/jira/browse/TINKERPOP-740 > Project: TinkerPop > Issue Type: Improvement > Components: driver, io, server >Affects Versions: 3.0.2-incubating >Reporter: stephen mallette >Assignee: stephen mallette > > Might be nice if Gremlin Server offered some way to tell the driver what > serializers it had (sorta thinking specifically of gryo) so that it could try > to use the same ones on the client. That way the user wouldn't need to hand > configure them to be the same and if some class wasn't present the driver > could fail early with a clear error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1133) ScriptRecordReader should allow any class implementing/extending RecordReader to bust up blocks, not just LineRecordReader
[
https://issues.apache.org/jira/browse/TINKERPOP-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15458759#comment-15458759
]
stephen mallette commented on TINKERPOP-1133:
-
[~dylanht] I was just doing some review of issues and saw this one hanging out
there. are you still interested in doing a tutorial on this topic?
> ScriptRecordReader should allow any class implementing/extending RecordReader
> to bust up blocks, not just LineRecordReader
> --
>
> Key: TINKERPOP-1133
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1133
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation, hadoop, io
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Dylan Bethune-Waddell
>Priority: Minor
>
> I stuck a slightly modified {{XmlRecordReader}} class from the Apache Mahout
> project into
> {{org.apache.tinkerpop.gremlin.hadoop.structure.io.script.ScriptRecordReader}}
> to bulk load XML with ScriptInputFormat, which I have notes on here:
> https://github.com/dylanht/thamyris
> I'm not sure what other formats would need a custom record reader, but why
> not allow it and let any class that implements {{RecordReader}} feed the
> user's groovy script? I was thinking the config would be something like:
> {code}
> // Enum for RecordReaders TinkerPop provides, otherwise fully
> qualified class name
> gremlin.hadoop.scriptInputFormat.reader=XML // vs. LINE or a.b.myReader
> // omit closing angled bracket to start block split before attributes
> gremlin.hadoop.scriptInputFormat.xml.startTag= gremlin.hadoop.scriptInputFormat.xml.endTag=
> // An idea for later, because the above has big issues with nested elements
> gremlin.hadoop.scriptInputFormat.xml.xpath=/top/customer[position()<3]
> {code}
> Hadoop's {{RecordReader}} interface has {{InterruptedException}} checked for
> several methods, whereas {{LineRecordReader}} doesn't throw it for the
> respective methods. That's fine if {{LineRecordReader}} is imported directly
> as it is now, or {{XmlRecordReader}} is a weird hidden inner class the way I
> had it before. But to initialize anything that implements {{RecordReader}},
> it seems {{LineRecordReader}} and {{XmlRecordReader}} both have to end up in
> the org.apache.tinkerpop.gremlin.hadoop.structure.io.script package with
> something like this added in:
> {code}
> // same for nextKeyValue, getCurrentKey, getCurrentValue, getProgress
> public void initialize() throws IOException, InterruptedException {
> // doesn't enclose things in a try/catch as is
> try { // things } catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> throw new RuntimeException(e.getMessage(), e);
> }
> }
> {code}
> I don't know how good an idea pulling {{LineRecordReader}} and
> {{XmlRecordReader}} into that package is, or how to handle the
> InterruptedException, and if there are more useful "RecordReader"
> classes that could be implemented I would like to know about them, so I
> thought I would throw this up here before trying a PR. What do you think?
> References:
> https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/RecordReader.java
> https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/lib/input/LineRecordReader.java
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1418) CoreTraversalTests depend on missing functionality
[
https://issues.apache.org/jira/browse/TINKERPOP-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1418:
Component/s: (was: structure)
(was: test-suite)
documentation
Issue Type: Improvement (was: Bug)
Made some minor reclassifications on the ticket given the previous comments.
> CoreTraversalTests depend on missing functionality
> --
>
> Key: TINKERPOP-1418
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1418
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.2.1
>Reporter: Benjamin Anderson
>Priority: Minor
>
> The {{shouldLoadVerticesViaVertices}} and {{shouldLoadEdgesViaEdges}} tests
> in
> [CoreTraversalTests.java|https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/CoreTraversalTest.java#L94-L110]
> appear to depend on unspecified functionality.
> The comment for the {{.vertices}} method in the Graph structure class does
> not specify that it should accept Vertex objects (except in [one odd
> place|https://github.com/apache/tinkerpop/blob/d696b38ab774dd46c6723d5c59aa7329f96b41e1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/Graph.java#L219])
> - as an implementor it reads as if it's intended to be called only with
> identifiers.
> [When these two tests were
> added|https://github.com/apache/tinkerpop/commit/da30a525ef626b8f13ffba0b7abada89b68eff6b]
> some functionality was included in GraphStep to handle mapping Vertex
> objects to their IDs; this functionality was [soon
> removed|https://github.com/apache/tinkerpop/commit/59028c8ad18f23609e31220a59717a2bc05b78af],
> however, and added to TinkerGraph. Incidentally, Titan [also implements the
> same
> functionality|https://github.com/thinkaurelius/titan/blob/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/tinkerpop/TitanBlueprintsTransaction.java#L113-L141].
> Is {{Graph.vertices(Object...)}} intended to gracefully handle an array of
> Vertex elements as well as an array of Vertex identifiers? If so, then it
> appears that the documentation in Graph.java needs some reworking. It'd also
> perhaps be unfortunate, stylistically, to add a third behavior to that
> method. If it's not intended to support that call, then it seems that these
> two methods (and perhaps others?) should be removed from the test suite.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [DISCUSS] Rename REST references to HTTP
I also agree that we should remove any reference to REST. +1 Jean-Baptiste On Thursday, 1 September 2016, Stephen Mallette wrote: > Robert Dale brought this issue up: > > https://issues.apache.org/jira/browse/TINKERPOP-1369 > > Basically - "The "REST API" follows exactly none of the tenets of being > RESTful. Suggest renaming it to HTTP API so as to not mislead developers as > to the design of the API." > > I agree with the technical assessment, but I don't know that the average > developer will make such distinctions as easily. People will begin > wondering where "REST" went and the questions will follow. Anyway, that's > my main reluctance with this ticket. if the consensus here is to make the > naming more technically correct, then we can leave the issue open for a > change in 3.3.0, otherwise I'd like to close and get another JIRA issue off > the board. :). > > Anyone feel strongly about this issue one way or the other? > -- Jean-Baptiste
[jira] [Closed] (TINKERPOP-1418) CoreTraversalTests depend on missing functionality
[
https://issues.apache.org/jira/browse/TINKERPOP-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1418.
---
Resolution: Done
Assignee: stephen mallette
Fix Version/s: 3.2.2
3.1.4
Improved javadoc and resolved via CTR on
https://github.com/apache/tinkerpop/commit/0fefa12cd5d5ff80da254242db7c5ef3ae2d69cf
> CoreTraversalTests depend on missing functionality
> --
>
> Key: TINKERPOP-1418
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1418
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.2.1
>Reporter: Benjamin Anderson
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.1.4, 3.2.2
>
>
> The {{shouldLoadVerticesViaVertices}} and {{shouldLoadEdgesViaEdges}} tests
> in
> [CoreTraversalTests.java|https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/CoreTraversalTest.java#L94-L110]
> appear to depend on unspecified functionality.
> The comment for the {{.vertices}} method in the Graph structure class does
> not specify that it should accept Vertex objects (except in [one odd
> place|https://github.com/apache/tinkerpop/blob/d696b38ab774dd46c6723d5c59aa7329f96b41e1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/Graph.java#L219])
> - as an implementor it reads as if it's intended to be called only with
> identifiers.
> [When these two tests were
> added|https://github.com/apache/tinkerpop/commit/da30a525ef626b8f13ffba0b7abada89b68eff6b]
> some functionality was included in GraphStep to handle mapping Vertex
> objects to their IDs; this functionality was [soon
> removed|https://github.com/apache/tinkerpop/commit/59028c8ad18f23609e31220a59717a2bc05b78af],
> however, and added to TinkerGraph. Incidentally, Titan [also implements the
> same
> functionality|https://github.com/thinkaurelius/titan/blob/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/tinkerpop/TitanBlueprintsTransaction.java#L113-L141].
> Is {{Graph.vertices(Object...)}} intended to gracefully handle an array of
> Vertex elements as well as an array of Vertex identifiers? If so, then it
> appears that the documentation in Graph.java needs some reworking. It'd also
> perhaps be unfortunate, stylistically, to add a third behavior to that
> method. If it's not intended to support that call, then it seems that these
> two methods (and perhaps others?) should be removed from the test suite.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Code Freeze 3.1.4/3.2.2
Ted, fixed up some javadoc on tp31 branch - meant to do it earlier in the week (but forgot unfortunately): https://issues.apache.org/jira/browse/TINKERPOP-1418 Updated CHANGELOG with the JIRA issue. Anyway, everything is looking pretty good for release next week. On Thu, Sep 1, 2016 at 6:21 PM, Stephen Mallette wrote: > Just published what I believe is the final 3.2.2-SNAPSHOT docs prior to > VOTE. > > http://tinkerpop.apache.org/docs/3.2.2-SNAPSHOT/ > > On Thu, Sep 1, 2016 at 3:38 PM, Ted Wilmes wrote: > >> Cool, thanks for the update. I had not merged tp31 back into master after >> my changelog updates so thanks for taking care of that. >> >> --Ted >> >> On Thu, Sep 1, 2016 at 12:54 PM, Stephen Mallette >> wrote: >> >> > Ted, I noticed some formatting problems in the headers for asciidoc on >> the >> > tp31 branch. I corrected those. I don't think you need to republish the >> > SNAPSHOT docs over that minor change. Obviously, we'd get the fixes in >> the >> > official release. I also implemented this on tp31: >> > >> > https://issues.apache.org/jira/browse/TINKERPOP-1416 >> > >> > I updated CHANGELOG manually since you already generated that stuff. >> > >> > >> > >> > On Wed, Aug 31, 2016 at 3:00 PM, Ted Wilmes wrote: >> > >> > > The 3.1.4-SNAPSHOT docs have been published to: >> http://tinkerpop.apache. >> > > org/docs/3.1.4-SNAPSHOT/ >> > > >> > > Changelog bugs and improvements have also been updated with where we >> > stand >> > > at this point with 3.1.4: >> > > https://github.com/apache/tinkerpop/blob/tp31/CHANGELOG.asciidoc >> > > >> > > Thanks, >> > > Ted >> > > >> > > >> > > >> > > >> > > On Sun, Aug 28, 2016 at 7:52 AM, Ted Wilmes >> wrote: >> > > >> > > > Hello, >> > > > The 3.1.4-SNAPSHOT has been published. As Stephen mentioned, we do >> not >> > > > expect any >> > > > non-doc changes/additions to tp31 but let me know if something comes >> > up. >> > > > I'll be reviewing >> > > > the docs and publishing a doc snapshot later this week. >> > > > >> > > > Thanks, >> > > > Ted >> > > > >> > > > On Sat, Aug 27, 2016 at 5:15 AM, Stephen Mallette < >> > spmalle...@gmail.com> >> > > > wrote: >> > > > >> > > >> Code freeze begins today. Some minor changes to expect on master: >> > > >> >> > > >> + We have one lingering PR that needs to be merged once it is >> rebased: >> > > >> https://github.com/apache/tinkerpop/pull/385 >> > > >> + I suspect we will see more tests on gremlin-python as well as >> tweaks >> > > to >> > > >> the build process >> > > >> + We may see one more serializers added to GraphSON 2.0 - >> > > >> TraversalExplanation >> > > >> + More docs as usual >> > > >> >> > > >> Recall, that gremlin-python and GraphSON 2.0 will be "experimental" >> > so I >> > > >> don't think we should be too concerned about late changes on that >> > stuff >> > > at >> > > >> this point. So - nothing major coming down the pike and as far as I >> > know >> > > >> there shouldn't be any change on tp31 branch aside from some added >> > > >> documentation. >> > > >> >> > > >> Providers should be free to test things out in their >> implementations. >> > > I've >> > > >> published the 3.2.2-SNAPSHOT to Apache Snapshots repo. Note that >> Ted >> > is >> > > >> going to be handling the 3.1.4 release - he will publish the >> > > >> 3.1.4-SNAPSHOT >> > > >> sometime soon (thanks for helping out with that Ted - it will be >> > > >> interesting to have two voices taking us through code freeze week >> into >> > > >> release).. >> > > >> >> > > >> As usual, please stay tuned to this thread for updates as we head >> to >> > > >> release. Thanks! >> > > >> >> > > > >> > > > >> > > >> > >> > >
