[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours

2019-05-30 Thread Daniel Kuppitz (JIRA) 


[ 
https://issues.apache.org/jira/browse/TINKERPOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852270#comment-16852270
 ] 

Daniel Kuppitz commented on TINKERPOP-2230:
---

To me it looked like the implementation made the assumption that patterns are 
always circular (e.g. you can pick a random start label and from there you can 
reach any other label). Also, the user-defined start step (the start step of 
your first pattern) was never moved, so if you came up with pre-sorted solvable 
sequence, you wouldn't have run into an error.

Now, bad things started to happen if there's a start label that is never used 
as an end label. The start step discovery algorithm didn't force this child 
pattern to be pushed to the top (and thus define the ultimate start label). 
Hence, you sometimes got the unsolvable pattern error, although all child 
patterns as a whole would have produced a valid pattern (if only the start step 
would have been be right).

> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b), 
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually 
> contains a solvable form of patterns. It's really confusing; if you want, 
> create a Jira ticket for that issue, perhaps someone dares to analyze that 
> crazy code"
> please see 
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
>  for more information.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours

2019-05-30 Thread Fabio Lorenzi (JIRA) 


[ 
https://issues.apache.org/jira/browse/TINKERPOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852023#comment-16852023
 ] 

Fabio Lorenzi commented on TINKERPOP-2230:
--

Is there some easy to explain reason? 

> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b), 
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually 
> contains a solvable form of patterns. It's really confusing; if you want, 
> create a Jira ticket for that issue, perhaps someone dares to analyze that 
> crazy code"
> please see 
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
>  for more information.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] TinkerPop 3.4.2 Release

2019-05-30 Thread Daniel Kuppitz 
*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.4.2-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop Gremlin ... OK
* validating Apache TinkerPop Gremlin's docs ... OK
* validating Apache TinkerPop Gremlin's binaries ... OK
* validating Apache TinkerPop Gremlin's legal files ...
  * LICENSE ... OK
  * NOTICE ... OK
* validating Apache TinkerPop Gremlin's plugin directory ... OK
* validating Apache TinkerPop Gremlin's lib directory ... OK
* testing script evaluation ... OK

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-server-3.4.2-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop Gremlin ... OK
* validating Apache TinkerPop Gremlin's docs ... OK
* validating Apache TinkerPop Gremlin's binaries ... OK
* validating Apache TinkerPop Gremlin's legal files ...
  * LICENSE ... OK
  * NOTICE ... OK
* validating Apache TinkerPop Gremlin's plugin directory ... OK
* validating Apache TinkerPop Gremlin's lib directory ... OK

Validating source distribution

* downloading Apache TinkerPop 3.4.2 (apache-tinkerpop-3.4.2-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.4.2 ... OK
* checking source files ... OK
* building project ... OK


VOTE +1


On Tue, May 28, 2019 at 1:34 PM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.4.2 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.2/
>
> The source distribution is provided by:
> apache-tinkerpop-3.4.2-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.4.2-bin.zip
> apache-tinkerpop-gremlin-server-3.4.2-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
> http://tinkerpop.apache.org/docs/3.4.2/ (user docs)
> http://tinkerpop.apache.org/docs/3.4.2/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.4.2/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.4.2/full/ (full javadoc)
> http://tinkerpop.apache.org/dotnetdocs/3.4.2/ (.NET API docs)
> http://tinkerpop.apache.org/jsdocs/3.4.2/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.4.2
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.4.2/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Firday (May 31,
> 2019) at 4:30pm EST.
>
> My vote is +1.
>
> Thank you very much,
>
> Stephen
>

[jira] [Commented] (TINKERPOP-2205) Use one connection per request for Java client

2019-05-30 Thread stephen mallette (JIRA) 


[ 
https://issues.apache.org/jira/browse/TINKERPOP-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16851970#comment-16851970
 ] 

stephen mallette commented on TINKERPOP-2205:
-

Given TINKERPOP-2132 seems to be solved by this body of work, I think this PR 
should include the tests I had in my branch (unless they duplicate tests 
already in this PR):

https://github.com/apache/tinkerpop/commit/329979e4c609b42866f1af80eb02860f195093c5#diff-2eb4fd75aa20b9b615aa8c20f5b54aa7

As for the rest of the changes in that commit, I'm not sure if we need to 
change the protocol anymore so perhaps we can just close TINKERPOP-2132 when 
this issue merges? 

> Use one connection per request for Java client
> --
>
> Key: TINKERPOP-2205
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2205
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.3.6
>Reporter: Divij Vaidya
>Priority: Major
>
> This issue is a tracking item for the conversation in the mailing list 
> [[1]|https://lists.apache.org/thread.html/77728cb77d4eab90f15680595e653ffc6055b74db29cbd4dcd5f0339@%3Cdev.tinkerpop.apache.org%3E]
>  which highlights multiple problems and shortcomings in the existing Java 
> client and proposes a design change in the client connection pooling to 
> address the same. More specifically, the problems addressed are as follows:
>  # Difficulty in configuring the client for optimum performance.
>  # Undocumented dependency of configuration parameters on each other.
>  # A bad request can impact other requests on the same channel.
>  # Host is marked as dead even if it is busy serving requests.
>  # No way to free up server resources if the client has stopped consuming 
> results.
>  # No differentiation between retriable and non-retriable exceptions from the 
> application code.
>  # Keep alive is only sent when a query is executing, which means that a 
> connection open for a very long time with no query being sent will be closed 
> by the server.
>  # Race condition if the server response reaches before result queue has been 
> registered.
>  # Unpredictable behaviour if the server sends an exception followed by a 
> genuine response for the same request.
>  # A concurrent hash map (tracking pending requests) is a point of contention 
> amongst threads.
> [1]https://lists.apache.org/thread.html/77728cb77d4eab90f15680595e653ffc6055b74db29cbd4dcd5f0339@%3Cdev.tinkerpop.apache.org%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2132) Authentication when using multiple threads fails

2019-05-30 Thread stephen mallette (JIRA) 


[ 
https://issues.apache.org/jira/browse/TINKERPOP-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16851969#comment-16851969
 ] 

stephen mallette commented on TINKERPOP-2132:
-

It seems that TINKERPOP-2205 solves this problem. The test I had in the 
comments above passes on that branch. Not sure if we need to have the breaking 
protocol level changes that I built in my branch. We probably need to make my 
tests part of that body of work though. 

> Authentication when using multiple threads fails
> 
>
> Key: TINKERPOP-2132
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2132
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.3.2
>Reporter: kaiyangzhang
>Assignee: stephen mallette
>Priority: Major
>
> *Scenes:*
>    1. Gremlin Server  Kerberos Authentication
>    2. Multithreading using the same client
>  
> {code:java}
>        DriverRemoteConnection connection = 
> DriverRemoteConnection.using(cluster,"graphbase");
>         GraphTraversalSource g = graph.traversal().withRemote(connection);
>       Thread demo1 = new Thread(new ThreadDemo1(g));
>        Thread demo2 = new Thread(new ThreadDemo1(g));
>        Thread demo3 = new Thread(new ThreadDemo1(g));
>        Thread demo4 = new Thread(new ThreadDemo1(g));
>        Thread demo5 = new Thread(new ThreadDemo1(g));
>       Thread demo6 = new Thread(new ThreadDemo1(g));
>        Thread demo7 = new Thread(new ThreadDemo1(g)); 
>        Thread demo8 = new Thread(new ThreadDemo1(g));
>        Thread demo9 = new Thread(new ThreadDemo1(g));
>        Thread demo10 = new Thread(new ThreadDemo1(g));
> {code}
>  
> *ERROR INFO*
> {code:java}
> Exception in thread "Thread-4" java.util.concurrent.CompletionException: 
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Failed to 
> authenticate
>  at 
> java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375)
>  at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934)
>  at org.apache.tinkerpop.gremlin.driver.ResultSet.one(ResultSet.java:107)
>  at 
> org.apache.tinkerpop.gremlin.driver.ResultSet$1.hasNext(ResultSet.java:159)
>  at org.apache.tinkerpop.gremlin.driver.ResultSet$1.next(ResultSet.java:166)
>  at org.apache.tinkerpop.gremlin.driver.ResultSet$1.next(ResultSet.java:153)
>  at 
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal$TraverserIterator.next(DriverRemoteTraversal.java:142)
>  at 
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal$TraverserIterator.next(DriverRemoteTraversal.java:127)
>  at 
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal.nextTraverser(DriverRemoteTraversal.java:108)
>  at 
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.processNextStart(RemoteStep.java:80)
>  at 
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
>  at 
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:192)
>  at com.huawei.graphbase.gremlin.ThreadDemo1.println(ThreadDemo1.java:48)
>  at com.huawei.graphbase.gremlin.ThreadDemo1.run(ThreadDemo1.java:32)
>  at java.lang.Thread.run(Thread.java:748)
>  Caused by: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: 
> Failed to authenticate
>  at 
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:246)
>  at 
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:197)
>  at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:373)
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:359)
>  at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:351)
>  at 
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinSaslAuthenticationHandler.channelRead0(Handler.java:123)
>  at 
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinSaslAuthenticationHandler.channelRead0(Handler.java:67)
>  at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:373)
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:359)
>  at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:351)
>  at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>  at 
>

[jira] [Commented] (TINKERPOP-2231) Remove deprecated bulk dumping/loading VertexPrograms

2019-05-30 Thread ASF GitHub Bot (JIRA) 


[ 
https://issues.apache.org/jira/browse/TINKERPOP-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16851867#comment-16851867
 ] 

ASF GitHub Bot commented on TINKERPOP-2231:
---

spmallette commented on pull request #1121: TINKERPOP-2231 Removed deprecated 
BulkLoader/DumperVertexProgram
URL: https://github.com/apache/tinkerpop/pull/1121
 
 
   https://issues.apache.org/jira/browse/TINKERPOP-2231
   
   Note that there are still some references to these classes in documentation. 
They were technically missed for removal in earlier versions. Will remove them 
from those branches for future releases and then merge forward.
   
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Remove deprecated bulk dumping/loading VertexPrograms
> -
>
> Key: TINKERPOP-2231
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2231
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.4.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
> Fix For: 3.5.0
>
>
> Both {{BulkDumperVertexProgram}} and {{BulkLoaderVertexProgram}} were 
> deprecated in 3.2.10 and replaced by {{CloneVertexProgram}}. Neither were 
> removed in 3.4.0 so as to give more time to providers relying on these 
> features to sort out their migration plans. Sufficient time has passed now 
> such that removing them for 3.5.0 should be generally agreeable to providers 
> and users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TINKERPOP-2232) RemoteStrategy does not call parent class TraversalStrategy __init__

2019-05-30 Thread James Farrow (JIRA) 


 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Farrow updated TINKERPOP-2232:

Description: 
Attempting to print the traversal_strategies property on a TraversalSource 
results in
{code:java}
AttributeError: 'RemoteStrategy' object has no attribute 'strategy_name' 
{code}
It appears RemoteStrategy.__init__ does not call its parent constructor 
TraversalSource.__init__ so strategy_name and configuration are not being 
initialised.

  was:
Attempting to print the traversal_strategies property on a TraversalSource 
results in

 
{code:java}
AttributeError: 'RemoteStrategy' object has no attribute 'strategy_name' 
{code}
It appears RemoteStrategy.__init__ does not call its parent constructor 
TraversalSource.__init__ so strategy_name and configuration are not being 
initialised.


> RemoteStrategy does not call parent class TraversalStrategy __init__
> 
>
> Key: TINKERPOP-2232
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2232
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.3.6, 3.4.1
>Reporter: James Farrow
>Priority: Minor
>
> Attempting to print the traversal_strategies property on a TraversalSource 
> results in
> {code:java}
> AttributeError: 'RemoteStrategy' object has no attribute 'strategy_name' 
> {code}
> It appears RemoteStrategy.__init__ does not call its parent constructor 
> TraversalSource.__init__ so strategy_name and configuration are not being 
> initialised.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (TINKERPOP-2232) RemoteStrategy does not call parent class TraversalStrategy __init__

2019-05-30 Thread James Farrow (JIRA) 
James Farrow created TINKERPOP-2232:
---

 Summary: RemoteStrategy does not call parent class 
TraversalStrategy __init__
 Key: TINKERPOP-2232
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2232
 Project: TinkerPop
  Issue Type: Bug
  Components: driver
Affects Versions: 3.4.1, 3.3.6
Reporter: James Farrow


Attempting to print the traversal_strategies property on a TraversalSource 
results in

 
{code:java}
AttributeError: 'RemoteStrategy' object has no attribute 'strategy_name' 
{code}
It appears RemoteStrategy.__init__ does not call its parent constructor 
TraversalSource.__init__ so strategy_name and configuration are not being 
initialised.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Some Asciidoc Tips and Fixes

2019-05-30 Thread Robert Dale 
I haven't added this to the docs yet.  As an update to #1, even `__` will
render as a nested emphasis if there is a following `__` in the same
paragraph, i.e. sentences touching, not separated by 2 or more newlines.
For example, http://tinkerpop.apache.org/docs/current/reference/

The source is:

NOTE: The `AnonymousTraversal` class above is just an alias for `__` as in
`from gremlin_python.process.graph_traversal import __ as
AnonymousTraversal`

Renders as:

The AnonymousTraversal class above is just an alias for *as infrom
gremlin_python.process.graph_traversal import *as AnonymousTraversal

Should be:

The AnonymousTraversal class above is just an alias for __ as in from
gremlin_python.process.graph_traversal import __ as AnonymousTraversal

This is fixed by the same method:  `+__+`.

Source fixed:

NOTE: The `AnonymousTraversal` class above is just an alias for `+__+` as in
`+from gremlin_python.process.graph_traversal import __ as
AnonymousTraversal+`


Robert Dale


On Tue, Apr 2, 2019 at 1:59 PM Stephen Mallette 
wrote:

> eh...looks like those two sections could be better handled. the intent for
> "Writing Documentation" was to give new contributors some basic
> instructions as to what was involved in doing that. the "Documentation"
> section is supposed to be for existing committers. maybe just push the
> details of of "Writing Documentation" down to "Documentation" and then add
> your new tips there? just leave enough in "Writing Documentation" to
> introduce new contributors to it and then add a link to "Documentation"? i
> don't have really strong feelings about how to organize it. if you think
> there is a better way to make that clean, feel free to propose something or
> just leave it as it is and add your stuff where you feel it best fits.
>
> On Tue, Apr 2, 2019 at 1:28 PM Robert Dale  wrote:
>
> > Should it be there
> > 
> or
> > here
> >
> >
> http://tinkerpop.apache.org/docs/3.4.1/dev/developer/#_writing_documentation
> >  ?
> >
> > Robert Dale
> >
> >
> > On Sat, Mar 30, 2019 at 9:35 AM Stephen Mallette 
> > wrote:
> >
> > > interesting - thanks for digging into this. do you mind doing a
> > > copy/paste/format of these tips to the dev docs so that they aren't
> lost
> > in
> > > the mailing list:
> > >
> > > http://tinkerpop.apache.org/docs/current/dev/developer/#documentation
> > >
> > >
> > >
> > > On Wed, Mar 27, 2019 at 6:23 AM Robert Dale  wrote:
> > >
> > > > 0. Asciidoctor is not Asciidoc (applications)
> > > >
> > > > This was not immediately obvious to me when I started.  I have found
> > that
> > > > Asciidoc renders the following scenarios correctly. However, our
> maven
> > > > build uses Asciidoctor which rendered incorrectly.  So if you write
> > > > asciidoc and use some tool to preview content and it looks good,
> verify
> > > > which tech it is using underneath. If it's not asciidoctor or you're
> > not
> > > > sure, it would be a good idea to use the command-line asciidoctor
> tool
> > or
> > > > even better to use the maven build.
> > > >
> > > >
> > > > 1. Two anonymous traversals (__) in inline code
> > > > This will cause the content between the two __ to become emphasized
> > > > (italicized)
> > > >
> > > > E.g.
> > > >
> > >
> >
> http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps
> > > >
> > > > To reduce the verbosity of the expression, it is good toimport static
> > > > org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.*.***. This
> > way,
> > > > instead of doing *.inE() for an anonymous traversal, it is possible
> to
> > > > simply write inE(). Be aware of language-specific reserved keywords
> > when
> > > > using anonymous traversals. For example, in and as are reserved
> > keywords
> > > in
> > > > Groovy, therefore you must use the verbose syntax *.in()** and *.as()
> > to
> > > > avoid collisions.
> > > >
> > > > Cause:
> > > > Asciidoctor doesn't always do literal pass-through. Appears to be a
> > > > limitation of their parser.
> > > > https://github.com/asciidoctor/asciidoctor/issues/1717
> > > > https://github.com/asciidoctor/asciidoctor/issues/1066
> > > >
> > > > Solution:
> > > > Instead of:
> > > > `from __ gremlin_python.process.graph_traversal import __ as
> > > > AnonymousTraversal`
> > > >
> > > > Use plus:
> > > > `+from __ gremlin_python.process.graph_traversal import __ as
> > > > AnonymousTraversal+`
> > > >
> > > > Or, use pass:
> > > > `pass:[from __ gremlin_python.process.graph_traversal import __ as
> > > > AnonymousTraversal]`
> > > >
> > > >
> > > > 2. Content immediately following backtick doesn't render correctly
> > > > There appear to be some exceptions.
> > > >
> > > > E.g.
> > > >
> > > >
> > >
> >
> https://github.com/apache/tinkerpop/blob/3.4.1/CHANGELOG.asciidoc#tinkerpop-312-release-date-april-8-2016
> > > >
> > > > Deprecated ScriptElementFactory and made the local StarGraph globally
> > > > available for

[DISCUSS] Official Support of GraphBinary

2019-05-30 Thread Stephen Mallette 
We did a bit of a soft release of GraphBinary in 3.4.0 calling it
"experimental" which I think was a good idea since we had changes going in
right up to 3.4.0 and only had Java support. I saw that Jorge created:

https://issues.apache.org/jira/browse/TINKERPOP-2229

which calls for Javascript support of GraphBinary and that made me think
that it might be smart to try to aim to add GraphBinary support to all GLVs
along the 3.4.x line of code with the idea that GraphBinary stays
"experimental" there. Then in 3.5.0 we look to make that feature official
and remove Gryo/GraphSON default configurations in favor of GraphBinary.
That gives us our first "big" feature for 3.5.0.

[jira] [Work started] (TINKERPOP-2231) Remove deprecated bulk dumping/loading VertexPrograms

2019-05-30 Thread stephen mallette (JIRA) 


 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on TINKERPOP-2231 started by stephen mallette.
---
> Remove deprecated bulk dumping/loading VertexPrograms
> -
>
> Key: TINKERPOP-2231
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2231
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.4.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
> Fix For: 3.5.0
>
>
> Both {{BulkDumperVertexProgram}} and {{BulkLoaderVertexProgram}} were 
> deprecated in 3.2.10 and replaced by {{CloneVertexProgram}}. Neither were 
> removed in 3.4.0 so as to give more time to providers relying on these 
> features to sort out their migration plans. Sufficient time has passed now 
> such that removing them for 3.5.0 should be generally agreeable to providers 
> and users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (TINKERPOP-2231) Remove deprecated bulk dumping/loading VertexPrograms

2019-05-30 Thread stephen mallette (JIRA) 
stephen mallette created TINKERPOP-2231:
---

 Summary: Remove deprecated bulk dumping/loading VertexPrograms
 Key: TINKERPOP-2231
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2231
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.4.1
Reporter: stephen mallette
Assignee: stephen mallette
 Fix For: 3.5.0


Both {{BulkDumperVertexProgram}} and {{BulkLoaderVertexProgram}} were 
deprecated in 3.2.10 and replaced by {{CloneVertexProgram}}. Neither were 
removed in 3.4.0 so as to give more time to providers relying on these features 
to sort out their migration plans. Sufficient time has passed now such that 
removing them for 3.5.0 should be generally agreeable to providers and users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

release branch changes

2019-05-30 Thread Stephen Mallette 
Note that the master branch is now on 3.5.0-SNAPSHOT and that we have a
tp34 branch for ongoing development of the 3.4.x release line. Please
rebase open PRs accordingly.