[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
All tests pass with `docker/build.sh -t -n -i`

VOTE +1


---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
All tests pass with `docker/build.sh -t -n -i`

VOTE +1


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1363) Cleanup Docker build script for next major release

[ASF GitHub Bot (JIRA)]

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

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

GitHub user dkuppitz opened a pull request:

https://github.com/apache/tinkerpop/pull/508

TINKERPOP-1363 Cleanup Docker build script for next major release

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

Not that i squashed all my commits into 2 commits, it looks like this was 
all done in no time, what a shame!

Anyway, Python stuff is now part of the base image (this change requires 
that you - the tester - rebuild your Docker images; just drop the old ones).

I've also cleaned up the docs, which contained some dead links to a Groovy 
site that longer exists. Furthermore I updated `grapeConfig.xml` - in the docs 
and the one used by the Docker build script. Note that your local 
`grapeConfig.xml` may look different and still work, but I swear, what we have 
in this PR is the only way to make it work a) in Docker and b) on brand new 
development machines. Any other configuration will likely lead to failures when 
you try to install Console plugins.

VOTE: +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1363

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/508.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 #508


commit d4cf1f2510ade945a2721857226c147540761ce2
Author: Daniel Kuppitz 
Date:   2016-09-13T00:30:34Z

Installed Python and Subversion in the Docker base image and enable Python 
GLV for every Docker build.

commit dfe0be596a8455c6caaceb01adf13a87720a5a9f
Author: Daniel Kuppitz 
Date:   2016-11-28T18:22:05Z

Updated grapeConfig.xml for both - Docker's build script and the docs.
Also fixed some issues in the plugin installation script.




> Cleanup Docker build script for next major release
> --
>
> Key: TINKERPOP-1363
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1363
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>  Labels: breaking
> Fix For: 3.3.0
>
>
> https://github.com/apache/tinkerpop/commit/2b9901d704c9c5cb1ad618b3cf67f9ec646cf5e5
> ^^ This commit contains a quick fix. The installation of setuptools should 
> happen in the Docker base image setup; however, this can only be done for the 
> next major release as it's a breaking change for the Docker build script 
> (developers will have to remove / rebuild their local base images).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #490: TINKERPOP-1474 GraphSON decode of Vertex and Ed...

[bjmoor]

Github user bjmoor closed the pull request at:

https://github.com/apache/tinkerpop/pull/490


---
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-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1565:
---

In the development branch, this is what the serializations look like:

*VERTEX*

{code}
{
  "@type": "g:Vertex",
  "@value": {
"id": {
  "@type": "g:Int32",
  "@value": 1
},
"label": "person",
"properties": {
  "name": [
{
  "id": {
"@type": "g:Int64",
"@value": 0
  },
  "value": "marko"
}
  ],
  "location": [
{
  "id": {
"@type": "g:Int64",
"@value": 6
  },
  "value": "san diego",
  "properties": {
"startTime": {
  "@type": "g:Int32",
  "@value": 1997
},
"endTime": {
  "@type": "g:Int32",
  "@value": 2001
}
  }
},
{
  "id": {
"@type": "g:Int64",
"@value": 7
  },
  "value": "santa cruz",
  "properties": {
"startTime": {
  "@type": "g:Int32",
  "@value": 2001
},
"endTime": {
  "@type": "g:Int32",
  "@value": 2004
}
  }
},
{
  "id": {
"@type": "g:Int64",
"@value": 8
  },
  "value": "brussels",
  "properties": {
"startTime": {
  "@type": "g:Int32",
  "@value": 2004
},
"endTime": {
  "@type": "g:Int32",
  "@value": 2005
}
  }
},
{
  "id": {
"@type": "g:Int64",
"@value": 9
  },
  "value": "santa fe",
  "properties": {
"startTime": {
  "@type": "g:Int32",
  "@value": 2005
}
  }
}
  ]
}
  }
}
{code}

*VERTEX PROPERTY*

{code}
{
  "@type": "g:VertexProperty",
  "@value": {
"id": {
  "@type": "g:Int64",
  "@value": 6
},
"value": "san diego",
"vertex": {
  "@type": "g:Int32",
  "@value": 1
},
"label": "location",
"properties": {
  "startTime": {
"@type": "g:Int32",
"@value": 1997
  },
  "endTime": {
"@type": "g:Int32",
"@value": 2001
  }
}
  }
}
{code}

*EDGE*

{code}
{
  "@type": "g:Edge",
  "@value": {
"id": {
  "@type": "g:Int32",
  "@value": 16
},
"label": "uses",
"inVLabel": "software",
"outVLabel": "person",
"inV": {
  "@type": "g:Int32",
  "@value": 11
},
"outV": {
  "@type": "g:Int32",
  "@value": 1
},
"properties": {
  "skill": {
"@type": "g:Int32",
"@value": 5
  }
}
  }
}
{code}

*VERTEX PROPERTY PROPERTY*

{code}
{
  "@type": "g:Property",
  "@value": {
"key": "startTime",
"value": {
  "@type": "g:Int32",
  "@value": 1997
},
"vertexProperty": {
  "id": {
"@type": "g:Int64",
"@value": 6
  },
  "label": "location",
  "value": "san diego",
  "vertex": {
"@type": "g:Int32",
"@value": 1
  }
}
  }
}
{code}

*EDGE PROPERTY*

{code}
{
  "@type": "g:Property",
  "@value": {
"key": "skill",
"value": {
  "@type": "g:Int32",
  "@value": 5
},
"edge": {
  "id": {
"@type": "g:Int32",
"@value": 16
  },
  "label": "uses",
  "inV": {
"@type": "g:Int32",
"@value": 11
  },
  "outV": {
"@type": "g:Int32",
"@value": 1
  }
}
  }
}
{code}

> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the 

[jira] [Commented] (TINKERPOP-1573) Bindings don't work in coalesce

[ASF GitHub Bot (JIRA)]

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

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

GitHub user okram opened a pull request:

https://github.com/apache/tinkerpop/pull/507

TINKERPOP-1573: Bindings don't work in coalesce

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

The solution to this problem uses `ThreadLocal`. It sucks, but I don't know 
of any other way of doing this. Whats funny is that I knew this problem existed 
as in my notes, the `ThreadLocal` solution is what I came up with back then. We 
just never had a test case the demonstrated the anonymous traversal bindings 
problem and thus, I never implemented the "solution."

VOTE +1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1573

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/507.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 #507






> Bindings don't work in coalesce
> ---
>
> Key: TINKERPOP-1573
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1573
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: Robert Dale
>
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('fof').property('key',234)
> ==>v[0]
> gremlin> b = new Bindings()
> ==>{}
> gremlin> 
> g.withBindings(b).V().has('fof','key',234).coalesce(__.V().has(b.of('l','fof'),
>  b.of('k', 'key'), b.of('v',234)), 
> __.addV(b.of('nl','fof')).property(b.of('sk','key'), 
> b.of('sv',234))).property(b.of('nk','newkey'), 
> b.of('nv','newvalue')).asAdmin().getBytecode()
> ==>[[], [V(), has(fof, key, 234), coalesce([[], [V(), has(fof, key, 234)]], 
> [[], [addV(fof), property(key, 234)]]), property(binding[nk=newkey], 
> binding[nv=newvalue])]]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

[davebshow]

Github user davebshow commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
As long as the driver returns a future with a compatible API, yes, it can 
be used with all Python versions. The snippet you provided will throw an error 
with an Asyncio or Tornado client, as you can only call 
[`result()`](https://docs.python.org/3/library/asyncio-task.html#asyncio.Future.result)
 on a completed future. You will typically need to `yield/yield from/await` it 
first depending on the Python version and driver (like in the examples provided 
above). However, the underlying coroutine will spawn independently, which means 
that even if you don't `yield/yield from/await`, but you wait long enough 
before calling `result()` it will complete. For example:

```python
future = g.V().promise(lambda t: t.toList())
assert not future.done()  # Future has not completed
await asyncio.sleep(5)  # Simulate doing a ton of other blocking stuff
assert future.done()  # Future has completed (assuming 5 seconds was enough 
time to complete)
result = future.result()  # Doesn't throw an error 
```


---
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.
---

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
I reconfirmed with the latest updates and reaffirm my +1 vote from before.

- On Docker, this builds cleanly with `docker/build.sh -t -n -i`
- On Mac, this builds cleanly with `mvn clean install 
-DskipIntegrationTests=false`
- On Windows, this builds cleanly with `mvn clean install -DskipTests`
  - Following it up with `mvn clean install -DskipIntegrationTests=false` 
succeeds all the way until `hadoop-gremlin`

```
[INFO] Apache TinkerPop ... SUCCESS [ 
11.578 s]
[INFO] Apache TinkerPop :: Gremlin Shaded . SUCCESS [  
3.609 s]
[INFO] Apache TinkerPop :: Gremlin Core ... SUCCESS [ 
45.703 s]
[INFO] Apache TinkerPop :: Gremlin Test ... SUCCESS [ 
15.797 s]
[INFO] Apache TinkerPop :: Gremlin Groovy . SUCCESS [ 
59.453 s]
[INFO] Apache TinkerPop :: Gremlin Groovy Test  SUCCESS [ 
10.000 s]
[INFO] Apache TinkerPop :: TinkerGraph Gremlin  SUCCESS [04:31 
min]
[INFO] Apache TinkerPop :: Hadoop Gremlin . FAILURE [06:13 
min]
```

Although this doesn't completely solve TinkerPop builds on Windows, it 
passes a lot more than it used to.



---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
I reconfirmed with the latest updates and reaffirm my +1 vote from before.

- On Docker, this builds cleanly with `docker/build.sh -t -n -i`
- On Mac, this builds cleanly with `mvn clean install 
-DskipIntegrationTests=false`
- On Windows, this builds cleanly with `mvn clean install -DskipTests`
  - Following it up with `mvn clean install -DskipIntegrationTests=false` 
succeeds all the way until `hadoop-gremlin`

```
[INFO] Apache TinkerPop ... SUCCESS [ 
11.578 s]
[INFO] Apache TinkerPop :: Gremlin Shaded . SUCCESS [  
3.609 s]
[INFO] Apache TinkerPop :: Gremlin Core ... SUCCESS [ 
45.703 s]
[INFO] Apache TinkerPop :: Gremlin Test ... SUCCESS [ 
15.797 s]
[INFO] Apache TinkerPop :: Gremlin Groovy . SUCCESS [ 
59.453 s]
[INFO] Apache TinkerPop :: Gremlin Groovy Test  SUCCESS [ 
10.000 s]
[INFO] Apache TinkerPop :: TinkerGraph Gremlin  SUCCESS [04:31 
min]
[INFO] Apache TinkerPop :: Hadoop Gremlin . FAILURE [06:13 
min]
```

Although this doesn't completely solve TinkerPop builds on Windows, it 
passes a lot more than it used to.



> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/490
  
yes - i think you can close this one since the work is already underway 
elsewhere. thanks for submitting this though.


> 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, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> 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.3.4#6332)

[GitHub] tinkerpop issue #490: TINKERPOP-1474 GraphSON decode of Vertex and Edge prop...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/490
  
yes - i think you can close this one since the work is already underway 
elsewhere. thanks for submitting this though.


---
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-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[ASF GitHub Bot (JIRA)]

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

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

Github user bjmoor commented on the issue:

https://github.com/apache/tinkerpop/pull/490
  
It looks like the work being done in TINKERPOP-1565 will be addressing the 
issue which this PR was attempting to address, and probably in a more effective 
manner.  Should I just close this PR?


> 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, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> 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.3.4#6332)

[jira] [Commented] (TINKERPOP-1573) Bindings don't work in coalesce

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1573:
---

Crap. I see why the problem exists. I can't believe we didn't have any test 
cases  for nested traversals... I don't see an easy solution :( ... trying...

> Bindings don't work in coalesce
> ---
>
> Key: TINKERPOP-1573
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1573
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: Robert Dale
>
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('fof').property('key',234)
> ==>v[0]
> gremlin> b = new Bindings()
> ==>{}
> gremlin> 
> g.withBindings(b).V().has('fof','key',234).coalesce(__.V().has(b.of('l','fof'),
>  b.of('k', 'key'), b.of('v',234)), 
> __.addV(b.of('nl','fof')).property(b.of('sk','key'), 
> b.of('sv',234))).property(b.of('nk','newkey'), 
> b.of('nv','newvalue')).asAdmin().getBytecode()
> ==>[[], [V(), has(fof, key, 234), coalesce([[], [V(), has(fof, key, 234)]], 
> [[], [addV(fof), property(key, 234)]]), property(binding[nk=newkey], 
> binding[nv=newvalue])]]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1572) Impossible to get DetachedVertex when Connecting via withRemote

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1572:
-

I agree - letting the serializer decide makes more sense imo

> Impossible to get DetachedVertex when Connecting via withRemote 
> 
>
> Key: TINKERPOP-1572
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1572
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.0-incubating, 3.2.3
>Reporter: Robert Dale
>Assignee: stephen mallette
>Priority: Minor
>
> Problem:
> Using gremlin-console:
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('foo').property('key','value')
> ==>v[0]
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
> {noformat}
> Works when is.testing=true
> {noformat}
> export JAVA_OPTIONS="-Dis.testing=true"
> # restart server
> # repeat above test, result is:
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex
> {noformat}
> Appears to be a condition in 
> org.apache.tinkerpop.gremlin.server.util.TraverserIterator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1573) Bindings don't work in coalesce

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-1573:


Looks like nested traversals:

{noformat}
gremlin> g.withBindings(b).V().has(b.of('l','fof'), b.of('k', 'key'), 
b.of('v',234)).where(__.has(b.of('l','fof'), b.of('k', 'key'), 
b.of('v',234))).asAdmin().getBytecode()
==>[[], [V(), has(binding[l=fof], binding[k=key], binding[v=234]), where([[], 
[has(fof, key, 234)]])]]

gremlin> g.withBindings(b).V().has('fof', 'key', 
234).where(__.has(b.of('l','fof'), b.of('k', 'key'), 
b.of('v',234))).asAdmin().getBytecode()
==>[[], [V(), has(fof, key, 234), where([[], [has(fof, key, 234)]])]]

{noformat}

> Bindings don't work in coalesce
> ---
>
> Key: TINKERPOP-1573
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1573
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: Robert Dale
>
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('fof').property('key',234)
> ==>v[0]
> gremlin> b = new Bindings()
> ==>{}
> gremlin> 
> g.withBindings(b).V().has('fof','key',234).coalesce(__.V().has(b.of('l','fof'),
>  b.of('k', 'key'), b.of('v',234)), 
> __.addV(b.of('nl','fof')).property(b.of('sk','key'), 
> b.of('sv',234))).property(b.of('nk','newkey'), 
> b.of('nv','newvalue')).asAdmin().getBytecode()
> ==>[[], [V(), has(fof, key, 234), coalesce([[], [V(), has(fof, key, 234)]], 
> [[], [addV(fof), property(key, 234)]]), property(binding[nk=newkey], 
> binding[nv=newvalue])]]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

[aboudreault]

Github user aboudreault commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
Except my initial concern, can you confirm we can use the latest way with 
all Python versions and with/without a custom driver? It would be nice to have 
an unified way that just works everywhere. The asyncio + tornado support are 
good additions.

```python
g.V().promise(lambda x: x.toList()).result()
```


---
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

[ASF GitHub Bot (JIRA)]

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

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

GitHub user okram opened a pull request:

https://github.com/apache/tinkerpop/pull/506

TINKERPOP-1389: Support Spark 2.0.0

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

This was a crazy rollercoaster ride, but we now have three good things:

1. A more efficient serialization model in `SparkGraphComputer` using 
`KryoSerializer` (Spark) and `GryoRegistrator` (TinkerPop). This always 
existed, but was not default and had some issues that needed to be resolved.
2. Support for Spark 2.0.0. Spark 1.x has a different API and 
`` so this was pretty significant.
3. A test infrastructure in hadoop-gremlin that verifies that `IoRegistry` 
works in both Giraph and Spark. Prior to this moment, custom serializers 
weren't tested, nor did they work correctly!

This work is primarily the efforts of @yucx (Spark 2.0 compliance) and 
@dalaro (serialization infrastructure). I simply mediated their respective 
contributions and cleaned/organized/tested things accordingly.

Here are the benchmarks against Friendster (2.5 billion edges). Note that 
the TinkerPop 3.3.x line has two times. The first is with `GryoSerializer` (the 
old model) and the second is with `GryoRegistrator` (the new model).

```
g.V().count() -- answer 12500 (125 million vertices)
- TinkerPop 3.0.0.MX: 2.5 hours
- TinkerPop 3.0.0:  1.5 hours
- TinkerPop 3.1.1:  23 minutes
- TinkerPop 3.2.0:  6.8 minutes (Spark 1.5.2)
- TinkerPop 3.2.0:  5.5 minutes (Spark 1.6.1)
- TinkerPop 3.2.1:  2.2 minutes (Spark 1.6.1)
- TinkerPop 3.3.x:  1.7/1.9 minutes (Spark 2.2.0)

g.V().out().count() -- answer 2586147869 (2.5 billion length-1 paths (i.e. 
edges))
- TinkerPop 3.0.0.MX:  unknown
- TinkerPop 3.0.0:  2.5 hours
- TinkerPop 3.1.1:  1.1 hours
- TinkerPop 3.2.0:  13 minutes  (Spark 1.5.2)
- TinkerPop 3.2.0:  12 minutes  (Spark 1.6.1)
- TinkerPop 3.2.1:  2.4 minutes (Spark 1.6.1)
- TinkerPop 3.3.x:  2.2/2.2 minutes (Spark 2.0.0)

g.V().out().out().count() -- answer 640528666156 (640 billion length-2 
paths)
- TinkerPop 3.2.0:  55 minutes(Spark 1.5.2)
- TinkerPop 3.2.0:  50 minutes(Spark 1.6.1)
- TinkerPop 3.2.1:  37 minutes(Spark 1.6.1)
- TinkerPop 3.3.x:  42/27 minutes (Spark 2.0.0)

g.V().out().out().out().count() -- answer 215664338057221 (215 trillion 
length 3-paths)
- TinkerPop 3.0.0.MX: 12.8 hours
- TinkerPop 3.0.0:  8.6 hours
- TinkerPop 3.1.1:  2.4 hours
- TinkerPop 3.2.0:  1.6 hours (Spark 1.5.2)
- TinkerPop 3.2.0:  1.5 hours (Spark 1.6.1)
- TinkerPop 3.2.1:  1.1 hours (Spark 1.6.1)
- TinkerPop 3.3.x:  1.4/0.8 hours (Spark 2.0.0)

g.V().out().out().out().out().count() -- answer 83841426570464575 (83 
quadrillion length 4-paths)
- TinkerPop 3.2.0:  2.1 hours (Spark 1.6.1)
- TinkerPop 3.2.1:  1.7 hours (Spark 1.6.1)
- TinkerPop 3.3.x:  2.0/1.2 hours (Spark 2.0.0)

g.V().out().out().out().out().out().count() -- answer -2280190503167902456 
!! I blew the long space -- 64-bit overflow.
- TinkerPop 3.2.0:  2.8 hours (Spark 1.6.1)
- TinkerPop 3.2.1:  2.2 hours (Spark 1.6.1)
- TinkerPop 3.3.x:  2.6/1.6 hours (Spark 2.0.0)

g.V().group().by(outE().count()).by(count()). 
- TinkerPop 3.2.0:  12  minutes (Spark 1.6.1)
- TinkerPop 3.2.1:  2.4 minutes (Spark 1.6.1)
- TinkerPop 3.3.x:  3.2/3.2 minutes (Spark 2.0.0)

g.V().groupCount().by(outE().count())
- TinkerPop 3.2.0:  12  minutes (Spark 1.6.1)
- TinkerPop 3.2.1:  2.7 minutes (Spark 1.6.1)
- TinkerPop 3.3.x:  2.2/2.2 minutes (Spark 2.0.0)
```

VOTE +1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1389

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/506.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 #506


commit f0c5a5f133635215b96ba3f2b7431706e23938b3
Author: yucx 
Date:   2016-09-02T06:11:58Z

TINKERPOP-1389 Support Spark 2.0

commit 2321117c1fb9f5927569d9d61fa28250916b4807
Author: Marko A. Rodriguez 
Date:   

[GitHub] tinkerpop pull request #506: TINKERPOP-1389: Support Spark 2.0.0

[okram]

GitHub user okram opened a pull request:

https://github.com/apache/tinkerpop/pull/506

TINKERPOP-1389: Support Spark 2.0.0

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

This was a crazy rollercoaster ride, but we now have three good things:

1. A more efficient serialization model in `SparkGraphComputer` using 
`KryoSerializer` (Spark) and `GryoRegistrator` (TinkerPop). This always 
existed, but was not default and had some issues that needed to be resolved.
2. Support for Spark 2.0.0. Spark 1.x has a different API and 
`` so this was pretty significant.
3. A test infrastructure in hadoop-gremlin that verifies that `IoRegistry` 
works in both Giraph and Spark. Prior to this moment, custom serializers 
weren't tested, nor did they work correctly!

This work is primarily the efforts of @yucx (Spark 2.0 compliance) and 
@dalaro (serialization infrastructure). I simply mediated their respective 
contributions and cleaned/organized/tested things accordingly.

Here are the benchmarks against Friendster (2.5 billion edges). Note that 
the TinkerPop 3.3.x line has two times. The first is with `GryoSerializer` (the 
old model) and the second is with `GryoRegistrator` (the new model).

```
g.V().count() -- answer 12500 (125 million vertices)
- TinkerPop 3.0.0.MX: 2.5 hours
- TinkerPop 3.0.0:  1.5 hours
- TinkerPop 3.1.1:  23 minutes
- TinkerPop 3.2.0:  6.8 minutes (Spark 1.5.2)
- TinkerPop 3.2.0:  5.5 minutes (Spark 1.6.1)
- TinkerPop 3.2.1:  2.2 minutes (Spark 1.6.1)
- TinkerPop 3.3.x:  1.7/1.9 minutes (Spark 2.2.0)

g.V().out().count() -- answer 2586147869 (2.5 billion length-1 paths (i.e. 
edges))
- TinkerPop 3.0.0.MX:  unknown
- TinkerPop 3.0.0:  2.5 hours
- TinkerPop 3.1.1:  1.1 hours
- TinkerPop 3.2.0:  13 minutes  (Spark 1.5.2)
- TinkerPop 3.2.0:  12 minutes  (Spark 1.6.1)
- TinkerPop 3.2.1:  2.4 minutes (Spark 1.6.1)
- TinkerPop 3.3.x:  2.2/2.2 minutes (Spark 2.0.0)

g.V().out().out().count() -- answer 640528666156 (640 billion length-2 
paths)
- TinkerPop 3.2.0:  55 minutes(Spark 1.5.2)
- TinkerPop 3.2.0:  50 minutes(Spark 1.6.1)
- TinkerPop 3.2.1:  37 minutes(Spark 1.6.1)
- TinkerPop 3.3.x:  42/27 minutes (Spark 2.0.0)

g.V().out().out().out().count() -- answer 215664338057221 (215 trillion 
length 3-paths)
- TinkerPop 3.0.0.MX: 12.8 hours
- TinkerPop 3.0.0:  8.6 hours
- TinkerPop 3.1.1:  2.4 hours
- TinkerPop 3.2.0:  1.6 hours (Spark 1.5.2)
- TinkerPop 3.2.0:  1.5 hours (Spark 1.6.1)
- TinkerPop 3.2.1:  1.1 hours (Spark 1.6.1)
- TinkerPop 3.3.x:  1.4/0.8 hours (Spark 2.0.0)

g.V().out().out().out().out().count() -- answer 83841426570464575 (83 
quadrillion length 4-paths)
- TinkerPop 3.2.0:  2.1 hours (Spark 1.6.1)
- TinkerPop 3.2.1:  1.7 hours (Spark 1.6.1)
- TinkerPop 3.3.x:  2.0/1.2 hours (Spark 2.0.0)

g.V().out().out().out().out().out().count() -- answer -2280190503167902456 
!! I blew the long space -- 64-bit overflow.
- TinkerPop 3.2.0:  2.8 hours (Spark 1.6.1)
- TinkerPop 3.2.1:  2.2 hours (Spark 1.6.1)
- TinkerPop 3.3.x:  2.6/1.6 hours (Spark 2.0.0)

g.V().group().by(outE().count()).by(count()). 
- TinkerPop 3.2.0:  12  minutes (Spark 1.6.1)
- TinkerPop 3.2.1:  2.4 minutes (Spark 1.6.1)
- TinkerPop 3.3.x:  3.2/3.2 minutes (Spark 2.0.0)

g.V().groupCount().by(outE().count())
- TinkerPop 3.2.0:  12  minutes (Spark 1.6.1)
- TinkerPop 3.2.1:  2.7 minutes (Spark 1.6.1)
- TinkerPop 3.3.x:  2.2/2.2 minutes (Spark 2.0.0)
```

VOTE +1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1389

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/506.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 #506


commit f0c5a5f133635215b96ba3f2b7431706e23938b3
Author: yucx 
Date:   2016-09-02T06:11:58Z

TINKERPOP-1389 Support Spark 2.0

commit 2321117c1fb9f5927569d9d61fa28250916b4807
Author: Marko A. Rodriguez 
Date:   2016-09-12T18:22:05Z

GryoSerializer uses HadoopPools so that gryo pools are not constantly 
produced (object reused stylie). This have increased the performance of 
GryoSerializer based jobs to that of the 3.2.x line prior to bumping to Spark 
2.0.

commit 

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1474:
-

i linked this over to TINKERPOP-1565 as this issue fits under the total body of 
this GraphSON/GLV work

> 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, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> 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.3.4#6332)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/490
  
@okram pinged me on the side and filled me in with some background info i 
wasn't aware of - the short of it is that a lot of work has been done in this 
area on the aforementioned tickets and if you'd like to contribute you should 
probably coordinate with those working on TINKERPOP-1565 at this point.


> 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, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> 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.3.4#6332)

[GitHub] tinkerpop issue #490: TINKERPOP-1474 GraphSON decode of Vertex and Edge prop...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/490
  
@okram pinged me on the side and filled me in with some background info i 
wasn't aware of - the short of it is that a lot of work has been done in this 
area on the aforementioned tickets and if you'd like to contribute you should 
probably coordinate with those working on TINKERPOP-1565 at this point.


---
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-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
It's been about a week since @davebshow laid out the approach he's 
recommending here. I assume the silence means that there are no objections to 
that approach and we have consensus on what to do? :)


> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
It's been about a week since @davebshow laid out the approach he's 
recommending here. I assume the silence means that there are no objections to 
that approach and we have consensus on what to do? :)


---
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.
---

Re: Bindings adavantage

[Marko Rodriguez]

Hi,

Bindings are useful for ScriptEngine-based Gremlin variants where the String 
script can be compiled and ScriptEngine.bindings can be set. That is, this is 
useful in parameterized scripts situations 
(http://tinkerpop.apache.org/docs/current/reference/#parameterized-scripts 
).

In Gremlin-Java, bindings are not useful as Java reflection is leveraged to 
construct the Traversal from Bytecode and it is already smokin’ fast to do so 
relative to String parsing a script.

Here are the runtimes. As you can see, bindings are important w/ Gremlin-Groovy 
and not so for Gremlin-Java.

gremlin> clock(1000){ JavaTranslator.of(g).translate(bytecode) } // reflection 
(Gremlin-Java)
==>0.004768085
gremlin> clock(1000){ compiled.eval(bindings) } // caching (Gremlin-Groovy)
==>0.015168259
gremlin> clock(1000){ groovy.reset(); 
groovy.eval(GroovyTranslator.of('g').translate(bytecode), bindings) } // no 
caching (Gremlin-Groovy)
==>40.790075693
gremlin>

HTH,
Marko.

http://markorodriguez.com



> On Nov 29, 2016, at 5:05 AM, Robert Dale  wrote:
> 
> I was looking at TINKERPOP-1444 and a conclusion was that Bytecode with
> Bindings can't be cached.  If that's true, is there any advantage to using
> Bindings?
> 
> Robert Dale

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
@okram the API changes seem to be due to your changes in 05bfb029. You 
could try and fill out your first intentional API changes list ;-)

(Most of the below is just git extravaganza - the important bits are points 
5, 6 and 7)

1. `git fetch <>`
1. `git checkout -b metlos-api-check-tp32 
<>/tp32`
1. `git pull https://github.com/metlos/tinkerpop api-check-tp32`
1. `mvn clean install -DskipTests`
1. copy and paste the JSON snippet output to the build console by revapi 
into `gremlin-core/api-changes.json`.
1. Follow the example in that file to ignore the found changes in `3.2.4` 
using the JSON snippet from the build.
1. Fill out the justifications for the changes in that snippet (making it a 
valid JSON).
1.  `git push ssh://g...@github.com/metlos/tinkerpop.git 
HEAD:api-check-tp32`
1. Watch this PR go green.


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[metlos]

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
@okram the API changes seem to be due to your changes in 05bfb029. You 
could try and fill out your first intentional API changes list ;-)

(Most of the below is just git extravaganza - the important bits are points 
5, 6 and 7)

1. `git fetch <>`
1. `git checkout -b metlos-api-check-tp32 
<>/tp32`
1. `git pull https://github.com/metlos/tinkerpop api-check-tp32`
1. `mvn clean install -DskipTests`
1. copy and paste the JSON snippet output to the build console by revapi 
into `gremlin-core/api-changes.json`.
1. Follow the example in that file to ignore the found changes in `3.2.4` 
using the JSON snippet from the build.
1. Fill out the justifications for the changes in that snippet (making it a 
valid JSON).
1.  `git push ssh://g...@github.com/metlos/tinkerpop.git 
HEAD:api-check-tp32`
1. Watch this PR go green.


---
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-1573) Bindings don't work in coalesce

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1573:
---

Weird. Is this specific to {{coalesce}} or nested traversals in general? 

> Bindings don't work in coalesce
> ---
>
> Key: TINKERPOP-1573
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1573
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: Robert Dale
>
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('fof').property('key',234)
> ==>v[0]
> gremlin> b = new Bindings()
> ==>{}
> gremlin> 
> g.withBindings(b).V().has('fof','key',234).coalesce(__.V().has(b.of('l','fof'),
>  b.of('k', 'key'), b.of('v',234)), 
> __.addV(b.of('nl','fof')).property(b.of('sk','key'), 
> b.of('sv',234))).property(b.of('nk','newkey'), 
> b.of('nv','newvalue')).asAdmin().getBytecode()
> ==>[[], [V(), has(fof, key, 234), coalesce([[], [V(), has(fof, key, 234)]], 
> [[], [addV(fof), property(key, 234)]]), property(binding[nk=newkey], 
> binding[nv=newvalue])]]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Bindings adavantage

[Robert Dale]

I was looking at TINKERPOP-1444 and a conclusion was that Bytecode with
Bindings can't be cached.  If that's true, is there any advantage to using
Bindings?

Robert Dale

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/490
  
TINKERPOP-1420 has merged to master. @bjmoor do you want to rebase your PR? 
note this area of development is still somewhat in flux on master given:

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

Perhaps the best option would be to target this work at the tp32 branch 
where GraphSON 2.0 is stable. wdyt?


> 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, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> 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.3.4#6332)

[GitHub] tinkerpop issue #490: TINKERPOP-1474 GraphSON decode of Vertex and Edge prop...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/490
  
TINKERPOP-1420 has merged to master. @bjmoor do you want to rebase your PR? 
note this area of development is still somewhat in flux on master given:

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

Perhaps the best option would be to target this work at the tp32 branch 
where GraphSON 2.0 is stable. wdyt?


---
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] [Created] (TINKERPOP-1573) Bindings don't work in coalesce

[Robert Dale (JIRA)]

Robert Dale created TINKERPOP-1573:
--

 Summary: Bindings don't work in coalesce
 Key: TINKERPOP-1573
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1573
 Project: TinkerPop
  Issue Type: Bug
  Components: structure
Affects Versions: 3.2.3
Reporter: Robert Dale


{noformat}
gremlin> graph = EmptyGraph.instance()
==>emptygraph[empty]
gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
==>graphtraversalsource[emptygraph[empty], standard]
gremlin> g.addV('fof').property('key',234)
==>v[0]
gremlin> b = new Bindings()
==>{}
gremlin> 
g.withBindings(b).V().has('fof','key',234).coalesce(__.V().has(b.of('l','fof'), 
b.of('k', 'key'), b.of('v',234)), 
__.addV(b.of('nl','fof')).property(b.of('sk','key'), 
b.of('sv',234))).property(b.of('nk','newkey'), 
b.of('nv','newvalue')).asAdmin().getBytecode()
==>[[], [V(), has(fof, key, 234), coalesce([[], [V(), has(fof, key, 234)]], 
[[], [addV(fof), property(key, 234)]]), property(binding[nk=newkey], 
binding[nv=newvalue])]]

{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1566) Kerberos authentication for gremlin-server

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1566:
-

sorry - i haven't had a chance to review this in any detail yet. i'll try to 
get to it soon

> 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
>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.3.4#6332)

[jira] [Commented] (TINKERPOP-1572) Impossible to get DetachedVertex when Connecting via withRemote

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1572:
-

oh - you're talking about {{withRemote}} not getting detached. yeah - it's 
currently designed to go always go to a reference. you can't get detached at 
this time.

> Impossible to get DetachedVertex when Connecting via withRemote 
> 
>
> Key: TINKERPOP-1572
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1572
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.2.0-incubating
>Reporter: Robert Dale
>Assignee: stephen mallette
>
> Problem:
> Using gremlin-console:
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('foo').property('key','value')
> ==>v[0]
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
> {noformat}
> Works when is.testing=true
> {noformat}
> export JAVA_OPTIONS="-Dis.testing=true"
> # restart server
> # repeat above test, result is:
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex
> {noformat}
> Appears to be a condition in 
> org.apache.tinkerpop.gremlin.server.util.TraverserIterator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1572) Impossible to get DetachedVertex when Connecting via withRemote

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-1572:


But you're still getting References not Detached.

> Impossible to get DetachedVertex when Connecting via withRemote 
> 
>
> Key: TINKERPOP-1572
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1572
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.2.0-incubating
>Reporter: Robert Dale
>Assignee: stephen mallette
>
> Problem:
> Using gremlin-console:
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('foo').property('key','value')
> ==>v[0]
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
> {noformat}
> Works when is.testing=true
> {noformat}
> export JAVA_OPTIONS="-Dis.testing=true"
> # restart server
> # repeat above test, result is:
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex
> {noformat}
> Appears to be a condition in 
> org.apache.tinkerpop.gremlin.server.util.TraverserIterator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TINKERPOP-1572) Impossible to get DetachedVertex when Connecting via withRemote

[stephen mallette (JIRA)]

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

stephen mallette edited comment on TINKERPOP-1572 at 11/29/16 11:46 AM:


works fine for me:

{code}
gremlin> :remote connect tinkerpop.server conf/remote-objects.yaml
==>Configured localhost/127.0.0.1:8182
gremlin> :> g.addV("name","stephen")
==>v[0]
gremlin> result.get(0).getObject().class
==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
{code}

or your way with "remote":

{code}
gremlin> graph = EmptyGraph.instance()
==>emptygraph[empty]
gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
==>graphtraversalsource[emptygraph[empty], standard]
gremlin> g.addV('foo').property('key','value')
==>v[0]
gremlin> g.V().next().getClass()
==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
{code}

Here's my {{remote-objects.yaml}} in full:

{code}
hosts: [localhost]
port: 8182
serializer: { className: 
org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0,
  config: { ioRegistries: 
[org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistry] }}
{code}


was (Author: spmallette):
works fine for me:

{code}
gremlin> :remote connect tinkerpop.server conf/remote-objects.yaml
==>Configured localhost/127.0.0.1:8182
gremlin> :> g.addV("name","stephen")
==>v[0]
gremlin> result.get(0).getObject().class
==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
{code}

or your way with "remote":

{code}
gremlin> graph = EmptyGraph.instance()
==>emptygraph[empty]
gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
==>graphtraversalsource[emptygraph[empty], standard]
gremlin> g.addV('foo').property('key','value')
==>v[0]
gremlin> g.V().next().getClass()
==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
{code}

Here's my {{remote.yaml}} in full:

{code}
hosts: [localhost]
port: 8182
serializer: { className: 
org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0,
  config: { ioRegistries: 
[org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistry] }}
{code}

> Impossible to get DetachedVertex when Connecting via withRemote 
> 
>
> Key: TINKERPOP-1572
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1572
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.2.0-incubating
>Reporter: Robert Dale
>Assignee: stephen mallette
>
> Problem:
> Using gremlin-console:
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('foo').property('key','value')
> ==>v[0]
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
> {noformat}
> Works when is.testing=true
> {noformat}
> export JAVA_OPTIONS="-Dis.testing=true"
> # restart server
> # repeat above test, result is:
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex
> {noformat}
> Appears to be a condition in 
> org.apache.tinkerpop.gremlin.server.util.TraverserIterator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1572) Impossible to get DetachedVertex when Connecting via withRemote

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1572:
-

works fine for me:

{code}
gremlin> :remote connect tinkerpop.server conf/remote-objects.yaml
==>Configured localhost/127.0.0.1:8182
gremlin> :> g.addV("name","stephen")
==>v[0]
gremlin> result.get(0).getObject().class
==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
{code}

or your way with "remote":

{code}
gremlin> graph = EmptyGraph.instance()
==>emptygraph[empty]
gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
==>graphtraversalsource[emptygraph[empty], standard]
gremlin> g.addV('foo').property('key','value')
==>v[0]
gremlin> g.V().next().getClass()
==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
{code}

Here's my {{remote.yaml}} in full:

{code}
hosts: [localhost]
port: 8182
serializer: { className: 
org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0,
  config: { ioRegistries: 
[org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistry] }}
{code}

> Impossible to get DetachedVertex when Connecting via withRemote 
> 
>
> Key: TINKERPOP-1572
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1572
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.2.0-incubating
>Reporter: Robert Dale
>Assignee: stephen mallette
>
> Problem:
> Using gremlin-console:
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('foo').property('key','value')
> ==>v[0]
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
> {noformat}
> Works when is.testing=true
> {noformat}
> export JAVA_OPTIONS="-Dis.testing=true"
> # restart server
> # repeat above test, result is:
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex
> {noformat}
> Appears to be a condition in 
> org.apache.tinkerpop.gremlin.server.util.TraverserIterator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)