[jira] [Commented] (TINKERPOP-1539) Create a ComplexTraversalTest with crazy nested gnarly traversals.

[ASF GitHub Bot (JIRA)]

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

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

GitHub user dkuppitz opened a pull request:

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

TINKERPOP-1539 Create a ComplexTraversalTest with crazy nested gnarly 
traversals.

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

Added 2 more tests, one for OLTP only and one for OLTP+OLAP. More tests 
should not be added as part of this PR; we can add more later whenever a good 
traversal appears on the mailing list or somewhere else in the real world.

`docker/build.sh -t -i -n` succeeded.

VOTE: +1

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

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

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

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


commit e01aa721fd13e6cb6591aa3f54314071e118a087
Author: Marko A. Rodriguez 
Date:   2016-11-28T22:49:08Z

Got ComplexTest setup for @dkuppitz to go to town on. I don't think we need 
to include a GroovyComplexTest because @spmallette is doing the work for 
master/ that gets rid of the need for gremlin-groovy-test and thus, no need to 
waste the energy/time on GroovyComplexTest.

commit c68b2154ddc83b5e11686a11588585e238ec2985
Author: Daniel Kuppitz 
Date:   2016-12-01T21:13:59Z

added two complex tests; one for OLTP only, one for OLTP and OLAP




> Create a ComplexTraversalTest with crazy nested gnarly traversals.
> --
>
> Key: TINKERPOP-1539
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1539
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, test-suite
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> Our {{ProcessSuite}} has numerous tests verifying the semantics of the 
> various steps. Unfortunately, these tests are on simple traversals focused on 
> exposing the step in question in isolation.
> It would be good to add {{ComplexTraversalTest}} to the {{ProcessSuite}} 
> which has traversals over the Grateful Dead graph (for complexity reasons) 
> doing:
> 1. Numerous nests.
> 2. Match/Select/Where complexities.
> 3. Global side-effect access and unrolling and injecting.
> 4. ... just a bunch of nasty stuff.
> This will give us much more confidence as we add more strategies and 
> potentially, mess up our algebra which isn't exposed by the simple 
> "flat'-traversals we current test with.
> [~dkuppitz] --- would you be interested in doing this?



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

[GitHub] tinkerpop pull request #511: TINKERPOP-1539 Create a ComplexTraversalTest wi...

[dkuppitz]

GitHub user dkuppitz opened a pull request:

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

TINKERPOP-1539 Create a ComplexTraversalTest with crazy nested gnarly 
traversals.

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

Added 2 more tests, one for OLTP only and one for OLTP+OLAP. More tests 
should not be added as part of this PR; we can add more later whenever a good 
traversal appears on the mailing list or somewhere else in the real world.

`docker/build.sh -t -i -n` succeeded.

VOTE: +1

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

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

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

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


commit e01aa721fd13e6cb6591aa3f54314071e118a087
Author: Marko A. Rodriguez 
Date:   2016-11-28T22:49:08Z

Got ComplexTest setup for @dkuppitz to go to town on. I don't think we need 
to include a GroovyComplexTest because @spmallette is doing the work for 
master/ that gets rid of the need for gremlin-groovy-test and thus, no need to 
waste the energy/time on GroovyComplexTest.

commit c68b2154ddc83b5e11686a11588585e238ec2985
Author: Daniel Kuppitz 
Date:   2016-12-01T21:13:59Z

added two complex tests; one for OLTP only, one for OLTP and OLAP




---
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=15713832#comment-15713832
 ] 

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

Github user asfgit closed the pull request at:

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


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

[GitHub] tinkerpop pull request #457: TINKERPOP-1493 Groovy project doesn't build on ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request #508: TINKERPOP-1363 Cleanup Docker build script for ...

[dkuppitz]

Github user dkuppitz commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/508#discussion_r90561817
  
--- Diff: CHANGELOG.asciidoc ---
@@ -26,6 +26,7 @@ 
image::https://raw.githubusercontent.com/apache/tinkerpop/master/docs/static/ima
 TinkerPop 3.3.0 (Release Date: NOT OFFICIALLY RELEASED YET)
 ~~~
 
+* Updated Docker build scripts to include Python dependencies (NOTE: users 
should remove any previously generated TinkerPop Docker images).
--- End diff --

Yea, I didn't add it there, because it's neither for users nor for 
providers. I could add a `Upgrading for Developers` section... Thoughts?


---
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-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=15713433#comment-15713433
 ] 

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

Github user dkuppitz commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/508#discussion_r90561817
  
--- Diff: CHANGELOG.asciidoc ---
@@ -26,6 +26,7 @@ 
image::https://raw.githubusercontent.com/apache/tinkerpop/master/docs/static/ima
 TinkerPop 3.3.0 (Release Date: NOT OFFICIALLY RELEASED YET)
 ~~~
 
+* Updated Docker build scripts to include Python dependencies (NOTE: users 
should remove any previously generated TinkerPop Docker images).
--- End diff --

Yea, I didn't add it there, because it's neither for users nor for 
providers. I could add a `Upgrading for Developers` section... Thoughts?


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

Re: [TinkerPop] gremlin-x

[Stephen Mallette]

I don't think HaltedTraverserStrategy is a good way to deal with properties
vs no properties. It really should be a function of the serializer. I say
that because I seem to remember that if the Vertex (or Edge or whatever) is
embedded in another object then the HaltedTraverserStrategy won't properly
do your bidding. Like:

g.V().groupCount()

will embed the Vertex in a Map. ReferenceFactory and DetachedFactory don't
traverse the tree of objects when detaching right now - a serializer
however will do that in the normal course of its work. So, perhaps
withDetachment() would hint to the serializer what kind of detachment it
wants.

On Thu, Dec 1, 2016 at 3:57 PM, Marko Rodriguez 
wrote:

> Ah. Yes. I concur Pieter.
>
> Then I think we need to get smart about “what data?” We sort of already do
> with HaltedTraverserStrategy but this is really specific to internal
> computing and GremlinServer. We could go deeper into this path with:
>
> g.withDetachment(…)
>   - Detach.reference // just ids
>   - Detach.reduced // ids, labels, keys, values (basically, what you need
> for toString())
>   - Detach.rich // property data included
>   - Detached.full // edge data included (basically, StarGraph)
>
>
> Next, GraphSON would have to specify a “subtype” to the various g:Element
> types.
>
> { @type:”g:Vertex", @detach:”reference", @value: { id:1 } }
>
>
> Then, we could add a method to Element.
>
> Element.detachment() -> Detach enum
>
>
> This way, users can always know what is available to them. Finally for
> cleanliness:
>
> Element.detach(Detach) -> Element
> Element.attach(Graph) -> Element (always a Detach.full element)
>
>
> Just spit-ballin’,
> Marko.
>
> http://markorodriguez.com
>
>
>
> On Dec 1, 2016, at 12:28 PM, pieter-gmail  wrote:
>
> Hi,
>
> "So with ReferenceElements, latency will be less too because it takes
> less time to construct the ReferenceVertex than it does to construct a
> DetachedVertex. Imagine a vertex with 100 properties and meta
> properties. ?!"
>
> But ReferencedElement does not have the properties so more round trips
> are needed increasing latency. One of the first things to make Sqlg at
> all usable was to make sure that a Vertex contains all of its
> properties. Else at least one more call is needed per Vertex. Its a
> latency killer. For those mostly few cases where the Vertex is so fat
> that it is slow to load and only a few properties are needed then
> g.V().hasLabel("label").values("property1", "property2") is used. So to
> my mind ReferencedElement increases latency and does not decreases it.
>
> Using ReferencedElement which is hardly an Element at all, after all it
> throws exceptions on almost all of its own interface, the user has to
> get the properties manually and then is back in a world of Map and Lists
> of Maps.
>
> A refactor of much existing code will need to toss the Vertex notion all
> together and replace it with Maps and Lists of Maps. Almost like writing
> an application in pure JDBC code with thousands of lines iterating
> through ResultSets mapping things back and forth. Unless I am missing
> something this change seems huge.
>
> I get that all this is important for non java devs but it be a pity if
> their problems becomes java devs problems.
>
> Cheers
> Pieter
>
>
> On 01/12/2016 20:38, Marko Rodriguez wrote:
>
> Hi,
>
> *PIETER REPLIES:*
>
> One of the first reasons I came to graphs, Neo4j and then TinkerPop way
> back was precisely because of the direct access to Node/Vertex. The user
> treats it like any other object, not a remote connection. It is the
> embedded nature that makes life so easy. In a way it was like having a
> simplistic Hibernate as the core api. 99% of queries we write is to
> retrieve vertices. Not Maps and Lists of something. TinkerPop's own test
> suite applies this type of thinking. Querying/modifying Elements and
> asserting them. Vertex and Edge abound as first class citizens.
>
>
> So Graph/Vertex/Edge/VertexProperty/Property will still exist for
> users as objects in the respective GLV language, it is just they are
> not “attached” and “rich.”
>
> For instance, in Gremlin-Python, you have:
>
>v = g.V().next()
>v.id
>
> A ReferenceVertex contains the id of the vertex so you can always
> “re-attach” it to the source.
>
>g.V(v).out()
>
>
> Graph, Vertex and Edge is the primary abstraction that users deal with.
> Having the direct representation of this is very very nice.
> It makes user code easy and readable.  You know you are dealing with the
> "Person/Address/Dog/This/That" entity/label as opposed to just a
> decontextualized bunch of data, Maps and Lists. If Vertex/Edge/Property
> were to disappear I'd say it would be the first call of duty to write a
> baby hibernate to bring the property model back in again into userspace.
>
>
> Again, the abstraction is still there, but just ALWAYS in a detached form.
>
>
> Regarding jdbc, this kinda makes the point. Sqlg and 

Updating Gremlin's Wikipedia page.

[Marko Rodriguez]

Hi,

Anyone interested in working on Gremlin’s Wikipedia page?

https://en.wikipedia.org/wiki/Gremlin_(programming_language) 


Discussing Gremlin bytecode would be good.

Bye,
Marko.

http://markorodriguez.com

[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=15713071#comment-15713071
 ] 

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

Here is an idea that I had with [~pietermartin-tinkerpop] on gremlin-users.



Then I think we need to get smart about “what data?” We sort of already do with 
{{HaltedTraverserStrategy}} but this is really specific to internal computing 
and GremlinServer. We could go deeper into this path with:

{code}
g.withDetachment(…)
  - Detach.reference // just ids
  - Detach.reduced // ids, labels, keys, values (basically, what you need for 
toString())
  - Detach.rich // property data included
  - Detached.full // edge data included (basically, StarGraph)
{code}

Next, GraphSON would have to specify a “subtype” to the various g:Element types.

{code}
{ @type:”g:Vertex", @detach:”reference", @value: { id:1 } }
{code}

Then, we could add a method to Element.

{code}
Element.detachment() -> Detach enum
{code}

This way, users can always know what is available to them. Finally for 
cleanliness:

{code}
Element.detach(Detach) -> Element
Element.attach(Graph) -> Element (always a Detach.full element)
{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
>Assignee: Marko A. Rodriguez
>  Labels: breaking
>
> 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 subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



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

[jira] [Commented] (TINKERPOP-1576) gremlin-python calls non-existent methods

[ASF GitHub Bot (JIRA)]

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

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

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/509
  
Yeah, `start()` could really lead to problems in client applications. I 
will remove  it from the statics.


> gremlin-python calls non-existent methods
> -
>
> Key: TINKERPOP-1576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1576
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Florian Hockmann
>Priority: Trivial
>
> The {{\_\_}} class calls two methods of the {{GraphTraversal}} class that are 
> not present in that class, namely: the constructor {{__()}} and {{start()}}
> {code}
> >>> __.__()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 401, in __
> return GraphTraversal(None, None, Bytecode()).__(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> {code}
> >>> __.start()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 623, in start
> return GraphTraversal(None, None, Bytecode()).start(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> This can be easily fixed by excluding those two methods in the 
> {{GraphTraversalSourceGenerator}}. I will create a pull request for that.



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

[GitHub] tinkerpop issue #509: TINKERPOP-1576 gremlin-python calls non-existent metho...

[FlorianHockmann]

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/509
  
Yeah, `start()` could really lead to problems in client applications. I 
will remove  it from the statics.


---
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-1576) gremlin-python calls non-existent methods

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/509
  
I would actually remove `start()` from static imports. Its never used as 
its more of a "helper method" and then less chance for naming collisions.



> gremlin-python calls non-existent methods
> -
>
> Key: TINKERPOP-1576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1576
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Florian Hockmann
>Priority: Trivial
>
> The {{\_\_}} class calls two methods of the {{GraphTraversal}} class that are 
> not present in that class, namely: the constructor {{__()}} and {{start()}}
> {code}
> >>> __.__()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 401, in __
> return GraphTraversal(None, None, Bytecode()).__(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> {code}
> >>> __.start()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 623, in start
> return GraphTraversal(None, None, Bytecode()).start(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> This can be easily fixed by excluding those two methods in the 
> {{GraphTraversalSourceGenerator}}. I will create a pull request for that.



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

[GitHub] tinkerpop issue #509: TINKERPOP-1576 gremlin-python calls non-existent metho...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/509
  
I would actually remove `start()` from static imports. Its never used as 
its more of a "helper method" and then less chance for naming collisions.



---
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-1576) gremlin-python calls non-existent methods

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/509
  
Perfect. VOTE +1.


> gremlin-python calls non-existent methods
> -
>
> Key: TINKERPOP-1576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1576
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Florian Hockmann
>Priority: Trivial
>
> The {{\_\_}} class calls two methods of the {{GraphTraversal}} class that are 
> not present in that class, namely: the constructor {{__()}} and {{start()}}
> {code}
> >>> __.__()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 401, in __
> return GraphTraversal(None, None, Bytecode()).__(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> {code}
> >>> __.start()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 623, in start
> return GraphTraversal(None, None, Bytecode()).start(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> This can be easily fixed by excluding those two methods in the 
> {{GraphTraversalSourceGenerator}}. I will create a pull request for that.



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

[jira] [Commented] (TINKERPOP-1576) gremlin-python calls non-existent methods

[ASF GitHub Bot (JIRA)]

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

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

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/509
  
Ok, I wasn't sure whether those methods make sense for a GLV, but it's good 
to know as I can now also implement it that way for the C# GLV.
My last commit adds hard-coded implementations for those methods. `__.__()` 
just calls `__.inject()` and `__.start()` returns an empty `GraphTraversal`. 
`start()` can also be called through _statics.py_.


> gremlin-python calls non-existent methods
> -
>
> Key: TINKERPOP-1576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1576
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Florian Hockmann
>Priority: Trivial
>
> The {{\_\_}} class calls two methods of the {{GraphTraversal}} class that are 
> not present in that class, namely: the constructor {{__()}} and {{start()}}
> {code}
> >>> __.__()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 401, in __
> return GraphTraversal(None, None, Bytecode()).__(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> {code}
> >>> __.start()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 623, in start
> return GraphTraversal(None, None, Bytecode()).start(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> This can be easily fixed by excluding those two methods in the 
> {{GraphTraversalSourceGenerator}}. I will create a pull request for that.



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

[GitHub] tinkerpop issue #509: TINKERPOP-1576 gremlin-python calls non-existent metho...

[FlorianHockmann]

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/509
  
Ok, I wasn't sure whether those methods make sense for a GLV, but it's good 
to know as I can now also implement it that way for the C# GLV.
My last commit adds hard-coded implementations for those methods. `__.__()` 
just calls `__.inject()` and `__.start()` returns an empty `GraphTraversal`. 
`start()` can also be called through _statics.py_.


---
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 #509: TINKERPOP-1576 gremlin-python calls non-existent metho...

[okram]

Github user okram commented on the issue:

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

Re: [TinkerPop] gremlin-x

[pieter-gmail]

Hi,

"So with ReferenceElements, latency will be less too because it takes
less time to construct the ReferenceVertex than it does to construct a
DetachedVertex. Imagine a vertex with 100 properties and meta
properties. ?!"

But ReferencedElement does not have the properties so more round trips
are needed increasing latency. One of the first things to make Sqlg at
all usable was to make sure that a Vertex contains all of its
properties. Else at least one more call is needed per Vertex. Its a
latency killer. For those mostly few cases where the Vertex is so fat
that it is slow to load and only a few properties are needed then
g.V().hasLabel("label").values("property1", "property2") is used. So to
my mind ReferencedElement increases latency and does not decreases it.

Using ReferencedElement which is hardly an Element at all, after all it
throws exceptions on almost all of its own interface, the user has to
get the properties manually and then is back in a world of Map and Lists
of Maps.

A refactor of much existing code will need to toss the Vertex notion all
together and replace it with Maps and Lists of Maps. Almost like writing
an application in pure JDBC code with thousands of lines iterating
through ResultSets mapping things back and forth. Unless I am missing
something this change seems huge.

I get that all this is important for non java devs but it be a pity if
their problems becomes java devs problems.

Cheers
Pieter


On 01/12/2016 20:38, Marko Rodriguez wrote:
> Hi,
>
> *PIETER REPLIES:*
>
>> One of the first reasons I came to graphs, Neo4j and then TinkerPop way
>> back was precisely because of the direct access to Node/Vertex. The user
>> treats it like any other object, not a remote connection. It is the
>> embedded nature that makes life so easy. In a way it was like having a
>> simplistic Hibernate as the core api. 99% of queries we write is to
>> retrieve vertices. Not Maps and Lists of something. TinkerPop's own test
>> suite applies this type of thinking. Querying/modifying Elements and
>> asserting them. Vertex and Edge abound as first class citizens.
>
> So Graph/Vertex/Edge/VertexProperty/Property will still exist for
> users as objects in the respective GLV language, it is just they are
> not “attached” and “rich.”
>
> For instance, in Gremlin-Python, you have:
>
> v = g.V().next()
> v.id
>
> A ReferenceVertex contains the id of the vertex so you can always
> “re-attach” it to the source.
>
> g.V(v).out()
>
>
>> Graph, Vertex and Edge is the primary abstraction that users deal with.
>> Having the direct representation of this is very very nice.
>> It makes user code easy and readable.  You know you are dealing with the
>> "Person/Address/Dog/This/That" entity/label as opposed to just a
>> decontextualized bunch of data, Maps and Lists. If Vertex/Edge/Property
>> were to disappear I'd say it would be the first call of duty to write a
>> baby hibernate to bring the property model back in again into userspace.
>
> Again, the abstraction is still there, but just ALWAYS in a detached form.
>
>>
>> Regarding jdbc, this kinda makes the point. Sqlg and Hibernate and many
>> many other tools exists precisely so that users do not need to use JDBC
>> with endless hardcoded strings guiding the application. Making TinkerPop
>> more like JDBC is not an obvious plus point.
>
> So, RemoteConnection differs from JDBC in that its not a fat string,
> but RemoteConnection.submit(Bytecode). Thus, you still work at the
> GraphTraversal level in every GLV.
>
>> A ReferencedElement is also no good as the problem I experience is
>> latency not bandwidth.
>
> So with ReferenceElements, latency will be less too because it takes
> less time to construct the ReferenceVertex than it does to construct a
> DetachedVertex. Imagine a vertex with 100 properties and meta
> properties. ?!
>
>> I reckon the experience and usage of TinkerPop is rather different for
>> java and non java people and perhaps even java folks. Hopefully I am not
>> the only one who have made such heavy happy use of the TinkerPop
>> property meta model and would be sad to see it go.
>>
>> Cheers
>> Pieter
>>
>
>
> *ROBERT REPLIES:*
>
>> I agree the focus should be on the Connection (being separate from
>> Graph) and Traversal. I wouldn't constrain it to "RemoteConnection",
>> just Connection or GraphConnection. Perhaps there's an
>> EmbeddedConnection and a RemoteConnection or maybe it's URI-oriented
>> similar to how JDBC does it. In either case, the behavior  of Remote
>> and Embedded is the same which is what I think we're striving for.
>
> Yes. Good point. Just Connection.
>
>> I would also like to see Transactions be Connection-oriented. With
>> the right API, it could hook into JTA and be able to take advantage
>> of various annotations for marking transaction boundaries.
>
> g = g.openTx()
> g.V().out().out()
> g.addV()
> g.V(1).addE().to(2)
> g.closeTx();
>
>
> ??? This way, its all about 

[jira] [Updated] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1565:

Fix Version/s: (was: 3.2.3)

The fix version was set to 3.2.3 - removed that. I assume this is targetted at 
3.3.0 (but didn't assign that)

> 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
>Assignee: Marko A. Rodriguez
>  Labels: breaking
>
> 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 subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



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

[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=15712732#comment-15712732
 ] 

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
We have enough votes to commit this. I'll handle it today. Thanks everyone.


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

[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
  
We have enough votes to commit this. I'll handle it today. Thanks everyone.


---
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-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=15712720#comment-15712720
 ] 

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/508
  
`docker/build.sh -t -i -n -d` worked for me. I ran a Docker build against 
`tp31` afterwards, and that worked too.

VOTE: +1


> 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 issue #508: TINKERPOP-1363 Cleanup Docker build script for next ma...

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/508
  
`docker/build.sh -t -i -n -d` worked for me. I ran a Docker build against 
`tp31` afterwards, and that worked too.

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-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=15712708#comment-15712708
 ] 

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

Github user pluradj commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/508#discussion_r90509684
  
--- Diff: CHANGELOG.asciidoc ---
@@ -26,6 +26,7 @@ 
image::https://raw.githubusercontent.com/apache/tinkerpop/master/docs/static/ima
 TinkerPop 3.3.0 (Release Date: NOT OFFICIALLY RELEASED YET)
 ~~~
 
+* Updated Docker build scripts to include Python dependencies (NOTE: users 
should remove any previously generated TinkerPop Docker images).
--- End diff --

should add this note to docs/src/upgrade/release-3.3.x.asciidoc 


> 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 #508: TINKERPOP-1363 Cleanup Docker build script for ...

[pluradj]

Github user pluradj commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/508#discussion_r90509684
  
--- Diff: CHANGELOG.asciidoc ---
@@ -26,6 +26,7 @@ 
image::https://raw.githubusercontent.com/apache/tinkerpop/master/docs/static/ima
 TinkerPop 3.3.0 (Release Date: NOT OFFICIALLY RELEASED YET)
 ~~~
 
+* Updated Docker build scripts to include Python dependencies (NOTE: users 
should remove any previously generated TinkerPop Docker images).
--- End diff --

should add this note to docs/src/upgrade/release-3.3.x.asciidoc 


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

Fwd: [TinkerPop] gremlin-x

[Marko Rodriguez]

Sorry, someone took out dev@ in the original email of my reply below.

Marko.

http://markorodriguez.com



> Begin forwarded message:
> 
> From: Marko Rodriguez 
> Subject: Re: [TinkerPop] gremlin-x
> Date: December 1, 2016 at 11:38:21 AM MST
> To: gremlin-us...@googlegroups.com
> 
> Hi,
> 
> PIETER REPLIES:
> 
>> One of the first reasons I came to graphs, Neo4j and then TinkerPop way
>> back was precisely because of the direct access to Node/Vertex. The user
>> treats it like any other object, not a remote connection. It is the
>> embedded nature that makes life so easy. In a way it was like having a
>> simplistic Hibernate as the core api. 99% of queries we write is to
>> retrieve vertices. Not Maps and Lists of something. TinkerPop's own test
>> suite applies this type of thinking. Querying/modifying Elements and
>> asserting them. Vertex and Edge abound as first class citizens.
> 
> So Graph/Vertex/Edge/VertexProperty/Property will still exist for users as 
> objects in the respective GLV language, it is just they are not “attached” 
> and “rich.”
> 
> For instance, in Gremlin-Python, you have:
> 
> v = g.V().next()
> v.id
>   
> A ReferenceVertex contains the id of the vertex so you can always “re-attach” 
> it to the source.
> 
> g.V(v).out()
> 
>> Graph, Vertex and Edge is the primary abstraction that users deal with.
>> Having the direct representation of this is very very nice.
>> It makes user code easy and readable.  You know you are dealing with the
>> "Person/Address/Dog/This/That" entity/label as opposed to just a
>> decontextualized bunch of data, Maps and Lists. If Vertex/Edge/Property
>> were to disappear I'd say it would be the first call of duty to write a
>> baby hibernate to bring the property model back in again into userspace.
> 
> Again, the abstraction is still there, but just ALWAYS in a detached form.
> 
>> 
>> Regarding jdbc, this kinda makes the point. Sqlg and Hibernate and many
>> many other tools exists precisely so that users do not need to use JDBC
>> with endless hardcoded strings guiding the application. Making TinkerPop
>> more like JDBC is not an obvious plus point.
> 
> So, RemoteConnection differs from JDBC in that its not a fat string, but 
> RemoteConnection.submit(Bytecode). Thus, you still work at the GraphTraversal 
> level in every GLV.
> 
>> A ReferencedElement is also no good as the problem I experience is
>> latency not bandwidth.
> 
> So with ReferenceElements, latency will be less too because it takes less 
> time to construct the ReferenceVertex than it does to construct a 
> DetachedVertex. Imagine a vertex with 100 properties and meta properties. ?!
> 
>> I reckon the experience and usage of TinkerPop is rather different for
>> java and non java people and perhaps even java folks. Hopefully I am not
>> the only one who have made such heavy happy use of the TinkerPop
>> property meta model and would be sad to see it go.
>> 
>> Cheers
>> Pieter
>> 
> 
> 
> ROBERT REPLIES:
> 
>> I agree the focus should be on the Connection (being separate from Graph) 
>> and Traversal. I wouldn't constrain it to "RemoteConnection", just 
>> Connection or GraphConnection. Perhaps there's an EmbeddedConnection and a 
>> RemoteConnection or maybe it's URI-oriented similar to how JDBC does it. In 
>> either case, the behavior  of Remote and Embedded is the same which is what 
>> I think we're striving for.
> 
> Yes. Good point. Just Connection.
> 
>> I would also like to see Transactions be Connection-oriented. With the right 
>> API, it could hook into JTA and be able to take advantage of various 
>> annotations for marking transaction boundaries.
> 
> g = g.openTx()
> g.V().out().out()
> g.addV()
> g.V(1).addE().to(2)
> g.closeTx();
> 
> ??? This way, its all about GraphTraversalSource/GraphTraversal. That is 
> truly the “connection” where the Connection implementation is just 
> provider/machine specific shuffling of Bytecode in and Traversers out.
> 
>> Are there features of a lambda that couldn't be replaced by a more 
>> feature-rich gremlin? 
>> g.V().out('knows').map{it.get().value('name') + ' is the friend name'}
>> g.V().out('knows').map(lambda(concat(__.it.get().value('name'), ' is the 
>> friend name’))
> 
> So we currently have the concept of g:Lambda and this allows for lambdas to 
> be used remotely.
> 
> g.V().map(function(“it.get().label()”)) // Gremlin-Java traversal with a 
> Gremlin-Groovy lambda.
> 
> The crappy thing is that the lambda is always a String.
> 
>> Reference-only makes total sense. This works really well especially with a 
>> local cache or for use cases where most of the data is stored in a separate 
>> database. I think it would lend itself nicely to lazy loading. When you need 
>> values there are options for that as well (properties/values/valueMap).  One 
>> of the problems with 'attached' elements is you don't know what the 
>> implementation does. So potentially every get or set property call is going 
>> 

Re: [TinkerPop] gremlin-x

[Stephen Mallette]

adding back dev

With Pieter's points in mind, Marko, ultimately does the "classic" embedded
mode to using TinkerPop go away for JVM users? I mean - it's not as though
those classes disappear. I suppose that in the end there's nothing we can
really do to prevent someone on the JVM from operating at the level Pieter
wants to operate at, right?

To me, I would think that gremlin-x/gremlin-java (or however it all shakes
out) is about exposing a body of code that provides the prescribed pattern
for developing applications with TinkerPop. So our user documentation would
cease to discuss what we've dubbed the "Structure API" and would instead
focus exclusively on the "Process API" ("structure" stuff would move to the
Provider Documentation). In many ways, I think that's a direction we've
been heading anyway. All the latest recipes have been written that way.
I've noticed SO and mailing list answers being written that way. It hasn't
been 100% consistent in terms of messaging but I guess we would look to use
this pivot point to start to do that.



On Thu, Dec 1, 2016 at 1:04 PM, pieter-gmail 
wrote:

> I was talking about we as users.
>
> One of the first reasons I came to graphs, Neo4j and then TinkerPop way
> back was precisely because of the direct access to Node/Vertex. The user
> treats it like any other object, not a remote connection. It is the
> embedded nature that makes life so easy. In a way it was like having a
> simplistic Hibernate as the core api. 99% of queries we write is to
> retrieve vertices. Not Maps and Lists of something. TinkerPop's own test
> suite applies this type of thinking. Querying/modifying Elements and
> asserting them. Vertex and Edge abound as first class citizens.
>
> Graph, Vertex and Edge is the primary abstraction that users deal with.
> Having the direct representation of this is very very nice.
>
> It makes user code easy and readable.  You know you are dealing with the
> "Person/Address/Dog/This/That" entity/label as opposed to just a
> decontextualized bunch of data, Maps and Lists. If Vertex/Edge/Property
> were to disappear I'd say it would be the first call of duty to write a
> baby hibernate to bring the property model back in again into userspace.
>
> Regarding jdbc, this kinda makes the point. Sqlg and Hibernate and many
> many other tools exists precisely so that users do not need to use JDBC
> with endless hardcoded strings guiding the application. Making TinkerPop
> more like JDBC is not an obvious plus point.
>
> A ReferencedElement is also no good as the problem I experience is
> latency not bandwidth.
>
> I reckon the experience and usage of TinkerPop is rather different for
> java and non java people and perhaps even java folks. Hopefully I am not
> the only one who have made such heavy happy use of the TinkerPop
> property meta model and would be sad to see it go.
>
> Cheers
> Pieter
>
>
> On 01/12/2016 17:53, Marko Rodriguez wrote:
> > Hello,
> >
> >> You say "v1.property(‘name’).value()" should never happen.
> >> This is something we use all the time. Almost all the work we do is with
> >> vertices and edges and is natural to call
> >> element.property("something").isPresent(),
> >> element.property("something").value(), element.property("something",
> >> "somethingnew”)
> >
> >
> > So “we” as “provider” or “we” as “user”?
> > * If provider, of course, internally, your TinkerPop implementation
> > and supporting code can use direct structure API calls.
> > * If user, then no, users should never talk to the structure API, only
> > the process API (i.e., traversal).
> >
> > Why so strict for “users"? A few reasons:
> >
> > 1. Think about Gremlin-Python. Users only gets back “proxy”
> > vertices/edges/etc. Thus, those users won’t be able to do what Java
> > users can. Inconsistent experience/documentation.
> > 2. Vertex/Edge/etc. methods are only useful in embedded systems as
> > remotely, even Gremlin-Java users just get proxies. Again,
> > inconsistent experience/documentation.
> > 3. We should not frame interactions with a graph system in terms of an
> > “API” as much as in terms of a “database connection.”
> > - So while MySQL JDBC returns row and column objects in a ResultSet,
> > they are just proxy containers of the data in MySQL. Mutating a
> > ResultSet doesn’t alter the MySQL data.
> >
> >> With this current train of thought will the use
> >> Graph/Vertex/Edge/Property be discouraged or disappear?
> >
> > For users, yes, save that they will get “proxy objects” like
> > ReferenceVertex/ReferenceEdge/etc. I strongly disagree with our use of
> > DetachedVertex/DetachedEdge/etc. for the reason that it exposes both
> > too much data (bandwidth) and DetachedXXX objects are intended to be
> > interacted with via the structure API — e.g.
> > vertex.property(“name”).isPresent().
> >
> >> Even as things stands now are you saying
> >> vertex.property("something").value() should be replaced with
> >> 

Re: [TinkerPop] gremlin-x

[Stephen Mallette]

> Something that should help performance and might help get away from
general scripts is batching

I've thought about batching as a feature many times, but i'm not sure it
solves the use case folks typically have that causes us problems. If most
batches looked like the one in your example that would be excellent, but I
think most "complex logic" tend to contain variables and and other looping
logic that you'd like to see as part of the batch. But maybe that's a
separate problem - if i have three unrelated traversals submitting them in
batch would be nice.

> Connection could also submit scripts. I still use scripts to access Graph
for db migration and performing schema updates.

hmm - we often forget the need for schema management. a key problem with
scripts is the security angle. we have a sandbox but it is bound to groovy
and i often wonder how well it could pass a rigorous security audit. It
also has the downside that it will force you to alter how you write scripts
in that they will be type-checked on evaluation.

In an effort to keep remoting about bytecode, perhaps we leverage some of
the work already done with lambdas. Somehow, you could initialize a remote
traversal with a lambda that could have an arbitrary script? in that way
it's still sent as bytecode and not another layer to the protocol? Perhaps
that same functionality could provide a way to access "complex logic" (i.e.
stored procedures) on the server in much the way that Neo4j has its "CALL"
in Cypher:

CALL org.neo4j.examples.findDenseNodes(1000)

Maybe there could be some sort of remote "call" step that let's us do
something like that. Sorry - this email is all over the place - just
tossing things out there.




On Thu, Dec 1, 2016 at 12:32 PM, Robert Dale  wrote:

> As someone who has gone through the trouble to migrate all scripts to Java
> withRemote, I'll throw in my $0.02.
>
> I agree the focus should be on the Connection (being separate from Graph)
> and Traversal. I wouldn't constrain it to "RemoteConnection", just
> Connection or GraphConnection. Perhaps there's an EmbeddedConnection and a
> RemoteConnection or maybe it's URI-oriented similar to how JDBC does it. In
> either case, the behavior  of Remote and Embedded is the same which is what
> I think we're striving for.
>
> I would also like to see Transactions be Connection-oriented. With the
> right API, it could hook into JTA and be able to take advantage of various
> annotations for marking transaction boundaries.
>
> An example of Connection:
>
> Connection con = new 
> GraphConnection("gremlin:server://localhost:8182/database");
> // returns RemoteConnection
> // con = new GraphConnection("gremlin:tinkergraph:in-mem/database"); //
> returns EmbeddedConnection
> // con = new GraphConnection("gremlin:neo4j:file://tmp/neo/database");
>
> con.setAutoCommit(false)
> con.tx().begin()
> g = con.traversal()
> g.addV().next()
> con.tx().commit()
>
> Connection could also submit scripts. I still use scripts to access Graph
> for db migration and performing schema updates.
> con.submit("g.V()").all()
>
> Something that should help performance and might help get away from
> general scripts is batching. Send all traversals at once:
>
> conn.batch(
>   g.addV(),
>   g.V().count(),
>   g.V()
> ).iterate()
>
> Are there features of a lambda that couldn't be replaced by a more
> feature-rich gremlin?
> g.V().out('knows').map{it.get().value('name') + ' is the friend name'}
> g.V().out('knows').map(lambda(concat(__.it.get().value('name'), ' is the
> friend name'))
>
> Reference-only makes total sense. This works really well especially with a
> local cache or for use cases where most of the data is stored in a separate
> database. I think it would lend itself nicely to lazy loading. When you
> need values there are options for that as well
> (properties/values/valueMap).  One of the problems with 'attached' elements
> is you don't know what the implementation does. So potentially every get or
> set property call is going to the database and you don't realize it. That
> can hurt performance and have unintended consequences.
>
> For loading graphs, Connection could also load and send raw GraphSON
> conn.load(new String(Files.readAllBytes(Paths.get("gremlin.gson" //
> perhaps a Stream would be better
> But maybe that should be reserved for the graph side.
>
> Still there should to be some sort of schema management interface or some
> way of accessing the Graph for live updates. Think when the database is
> embedded in a remote gremlin server (ala Neo4j). Otherwise the gremlin
> server would have to be shutdown, restart with native tools, perform work,
> shutdown, restart gremlin server. Maybe it's vendor-specific on the
> Connection implementation. Maybe it's just a limitation of using embedded
> DBs going forward (Neo4j 3.x has remote capabilities). Maybe this is moot
> if the GLV is the machine.  Just something to consider.
>
>
> Robert Dale
>
> On Thu, Dec 1, 2016 at 

[jira] [Closed] (TINKERPOP-1580) Resolve naming collisions for static imports in the Gremlin language

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1580.
---
Resolution: Duplicate

> Resolve naming collisions for static imports in the Gremlin language
> 
>
> Key: TINKERPOP-1580
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1580
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>
> This may not be a breaking change - it can likely be done with deprecation 
> along the 3.2.x line. The problem is that static imports collide in the 
> {{GremlinScriptEngine}} and therefore there are not only situations where 
> certain imports will be "hidden" but it can cause the system behave in 
> non-deterministic fashion depending on the {{ScriptEngine}}. For example, 
> groovy's compiler seems to only be able to detect the difference between 
> {{Column.values}} and {{__.values()}} if wildcards are used. If they are 
> imported directly then one of the other will fail.
> Here's a list of the troublemaker names that collide across different 
> methods/enums: or,and,id,values,key,local,value,sum,min,max.



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

[jira] [Created] (TINKERPOP-1579) Resolve naming collisions for static imports in the Gremlin language

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1579:
---

 Summary: Resolve naming collisions for static imports in the 
Gremlin language
 Key: TINKERPOP-1579
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1579
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.3
Reporter: stephen mallette


This may not be a breaking change - it can likely be done with deprecation 
along the 3.2.x line. The problem is that static imports collide in the 
{{GremlinScriptEngine}} and therefore there are not only situations where 
certain imports will be "hidden" but it can cause the system behave in 
non-deterministic fashion depending on the {{ScriptEngine}}. For example, 
groovy's compiler seems to only be able to detect the difference between 
{{Column.values}} and {{__.values()}} if wildcards are used. If they are 
imported directly then one of the other will fail.

Here's a list of the troublemaker names that collide across different 
methods/enums: or,and,id,values,key,local,value,sum,min,max.





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

[jira] [Created] (TINKERPOP-1580) Resolve naming collisions for static imports in the Gremlin language

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1580:
---

 Summary: Resolve naming collisions for static imports in the 
Gremlin language
 Key: TINKERPOP-1580
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1580
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.3
Reporter: stephen mallette


This may not be a breaking change - it can likely be done with deprecation 
along the 3.2.x line. The problem is that static imports collide in the 
{{GremlinScriptEngine}} and therefore there are not only situations where 
certain imports will be "hidden" but it can cause the system behave in 
non-deterministic fashion depending on the {{ScriptEngine}}. For example, 
groovy's compiler seems to only be able to detect the difference between 
{{Column.values}} and {{__.values()}} if wildcards are used. If they are 
imported directly then one of the other will fail.

Here's a list of the troublemaker names that collide across different 
methods/enums: or,and,id,values,key,local,value,sum,min,max.





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

Re: [TinkerPop] gremlin-x

[Robert Dale]

As someone who has gone through the trouble to migrate all scripts to Java
withRemote, I'll throw in my $0.02.

I agree the focus should be on the Connection (being separate from Graph)
and Traversal. I wouldn't constrain it to "RemoteConnection", just
Connection or GraphConnection. Perhaps there's an EmbeddedConnection and a
RemoteConnection or maybe it's URI-oriented similar to how JDBC does it. In
either case, the behavior  of Remote and Embedded is the same which is what
I think we're striving for.

I would also like to see Transactions be Connection-oriented. With the
right API, it could hook into JTA and be able to take advantage of various
annotations for marking transaction boundaries.

An example of Connection:

Connection con = new
GraphConnection("gremlin:server://localhost:8182/database");
// returns RemoteConnection
// con = new GraphConnection("gremlin:tinkergraph:in-mem/database"); //
returns EmbeddedConnection
// con = new GraphConnection("gremlin:neo4j:file://tmp/neo/database");

con.setAutoCommit(false)
con.tx().begin()
g = con.traversal()
g.addV().next()
con.tx().commit()

Connection could also submit scripts. I still use scripts to access Graph
for db migration and performing schema updates.
con.submit("g.V()").all()

Something that should help performance and might help get away from general
scripts is batching. Send all traversals at once:

conn.batch(
  g.addV(),
  g.V().count(),
  g.V()
).iterate()

Are there features of a lambda that couldn't be replaced by a more
feature-rich gremlin?
g.V().out('knows').map{it.get().value('name') + ' is the friend name'}
g.V().out('knows').map(lambda(concat(__.it.get().value('name'), ' is the
friend name'))

Reference-only makes total sense. This works really well especially with a
local cache or for use cases where most of the data is stored in a separate
database. I think it would lend itself nicely to lazy loading. When you
need values there are options for that as well
(properties/values/valueMap).  One of the problems with 'attached' elements
is you don't know what the implementation does. So potentially every get or
set property call is going to the database and you don't realize it. That
can hurt performance and have unintended consequences.

For loading graphs, Connection could also load and send raw GraphSON
conn.load(new String(Files.readAllBytes(Paths.get("gremlin.gson" //
perhaps a Stream would be better
But maybe that should be reserved for the graph side.

Still there should to be some sort of schema management interface or some
way of accessing the Graph for live updates. Think when the database is
embedded in a remote gremlin server (ala Neo4j). Otherwise the gremlin
server would have to be shutdown, restart with native tools, perform work,
shutdown, restart gremlin server. Maybe it's vendor-specific on the
Connection implementation. Maybe it's just a limitation of using embedded
DBs going forward (Neo4j 3.x has remote capabilities). Maybe this is moot
if the GLV is the machine.  Just something to consider.


Robert Dale

On Thu, Dec 1, 2016 at 10:53 AM, Marko Rodriguez 
wrote:

> Hello,
>
> You say "v1.property(‘name’).value()" should never happen.
> This is something we use all the time. Almost all the work we do is with
> vertices and edges and is natural to call
> element.property("something").isPresent(),
> element.property("something").value(), element.property("something",
> "somethingnew”)
>
>
>
> So “we” as “provider” or “we” as “user”?
> * If provider, of course, internally, your TinkerPop implementation and
> supporting code can use direct structure API calls.
> * If user, then no, users should never talk to the structure API, only the
> process API (i.e., traversal).
>
> Why so strict for “users"? A few reasons:
>
> 1. Think about Gremlin-Python. Users only gets back “proxy”
> vertices/edges/etc. Thus, those users won’t be able to do what Java users
> can. Inconsistent experience/documentation.
> 2. Vertex/Edge/etc. methods are only useful in embedded systems as
> remotely, even Gremlin-Java users just get proxies. Again, inconsistent
> experience/documentation.
> 3. We should not frame interactions with a graph system in terms of an
> “API” as much as in terms of a “database connection.”
> - So while MySQL JDBC returns row and column objects in a ResultSet, they
> are just proxy containers of the data in MySQL. Mutating a ResultSet
> doesn’t alter the MySQL data.
>
> With this current train of thought will the use
> Graph/Vertex/Edge/Property be discouraged or disappear?
>
>
> For users, yes, save that they will get “proxy objects” like
> ReferenceVertex/ReferenceEdge/etc. I strongly disagree with our use of
> DetachedVertex/DetachedEdge/etc. for the reason that it exposes both too
> much data (bandwidth) and DetachedXXX objects are intended to be interacted
> with via the structure API — e.g. vertex.property(“name”).isPresent().
>
> Even as things stands now are you saying
> 

[jira] [Commented] (TINKERPOP-1578) Support writable distributed graphs using spark as the underlying engine

[Dovid Kopel (JIRA)]

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

Dovid Kopel commented on TINKERPOP-1578:


So far I haven't touched graph computer at allit's the original one

Dovid Kopel
do...@dovidkopel.com
443-291-9212
Sent from my Android.




> Support writable distributed graphs using spark as the underlying engine
> 
>
> Key: TINKERPOP-1578
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1578
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dovid Kopel
>




--
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=15712397#comment-15712397
 ] 

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

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/508
  
`docker/build.sh -t -i -n -d` passed and I took a look at the docs and 
confirmed they generated correctly.

VOTE: +1


> 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 issue #508: TINKERPOP-1363 Cleanup Docker build script for next ma...

[twilmes]

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/508
  
`docker/build.sh -t -i -n -d` passed and I took a look at the docs and 
confirmed they generated correctly.

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-1562) Migrate ScriptEngine-related code to gremlin-core

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/510
  
@okram one thing that could use your explict review here - we lost the 
ability to do wildcard imports given the work you did on `CoreImports` for 
gremlin-python. Some plugins used a lot of wildcards, specifically the hadoop 
plugin:


https://github.com/apache/tinkerpop/blob/90f427c8dc11636a5884e6cca3c0a22249d26576/hadoop-gremlin/src/main/java/org/apache/tinkerpop/gremlin/hadoop/jsr223/HadoopGremlinPlugin.java

I didn't go through hadoop APIs to add all the classes that were 
wildcarded. can you please give a review to see if anything else should be 
added there?



> Migrate ScriptEngine-related code to gremlin-core
> -
>
> Key: TINKERPOP-1562
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1562
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
>  Labels: breaking
>
> Migrate classes and features of {{ScriptEngine}} to gremlin-core and 
> {{GremlinScriptEngine}}. There is a minor breaking change where the 
> {{ImportCustomizer}} class needs to become an interface. As the class itself 
> played no real role in operations of 3.2.3 it's doubtful that this should be 
> a big breaking change for users as no one was likely using it.



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

[GitHub] tinkerpop issue #510: TINKERPOP-1562 Migrate ScriptEngine-related code to gr...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/510
  
@okram one thing that could use your explict review here - we lost the 
ability to do wildcard imports given the work you did on `CoreImports` for 
gremlin-python. Some plugins used a lot of wildcards, specifically the hadoop 
plugin:


https://github.com/apache/tinkerpop/blob/90f427c8dc11636a5884e6cca3c0a22249d26576/hadoop-gremlin/src/main/java/org/apache/tinkerpop/gremlin/hadoop/jsr223/HadoopGremlinPlugin.java

I didn't go through hadoop APIs to add all the classes that were 
wildcarded. can you please give a review to see if anything else should be 
added there?



---
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: [TinkerPop] gremlin-x

[Marko Rodriguez]

Hello,

> You say "v1.property(‘name’).value()" should never happen.
> This is something we use all the time. Almost all the work we do is with
> vertices and edges and is natural to call
> element.property("something").isPresent(),
> element.property("something").value(), element.property("something",
> "somethingnew”)


So “we” as “provider” or “we” as “user”?
* If provider, of course, internally, your TinkerPop implementation and 
supporting code can use direct structure API calls.
* If user, then no, users should never talk to the structure API, only 
the process API (i.e., traversal).

Why so strict for “users"? A few reasons:

1. Think about Gremlin-Python. Users only gets back “proxy” 
vertices/edges/etc. Thus, those users won’t be able to do what Java users can. 
Inconsistent experience/documentation.
2. Vertex/Edge/etc. methods are only useful in embedded systems as 
remotely, even Gremlin-Java users just get proxies. Again, inconsistent 
experience/documentation.
3. We should not frame interactions with a graph system in terms of an 
“API” as much as in terms of a “database connection.”
- So while MySQL JDBC returns row and column objects in a 
ResultSet, they are just proxy containers of the data in MySQL. Mutating a 
ResultSet doesn’t alter the MySQL data.

> With this current train of thought will the use
> Graph/Vertex/Edge/Property be discouraged or disappear?

For users, yes, save that they will get “proxy objects” like 
ReferenceVertex/ReferenceEdge/etc. I strongly disagree with our use of 
DetachedVertex/DetachedEdge/etc. for the reason that it exposes both too much 
data (bandwidth) and DetachedXXX objects are intended to be interacted with via 
the structure API — e.g. vertex.property(“name”).isPresent().

> Even as things stands now are you saying
> vertex.property("something").value() should be replaced with
> g.V(vertex).values("something”)?

For users, yes.

Note that there is one problem:

Graph.addVertex() is way faster than g.addV(). Why? Graph.addVertex() is a 
direct method call to Graph without the complication of traversal compilation 
and Traverser encapsulation. We need to make the graph traversal way of CRUD to 
a graph system (nearly) as fast as direct structure API calls. Solutions:

1. A MutationStrategy that ultimately compile g.addV() to just 
Graph.addVertex() without all the fluff of Step semantics.
2. Strategy loading should be tied to step usage. In other words, why 
would we call MatchPredicateStrategy on a traversal that is g.addV()? The use 
of match() should trigger the loading of that strategy.
3. Make strategy application faster as it currently stands. This is 
linear improvement, but still, why not.

Thoughts?,
Marko.

http://markorodriguez .com


> 
> Thanks
> Pieter
> 
> 
> On 01/12/2016 16:43, Marko Rodriguez wrote:
>> Hi,
>> 
>>> I think we've tried a lot of things for TinkerPop 3 and that there
>>> are too many options for application development as well as an
>>> over-exposed API, so I like this direction, though a fair bit of
>>> complexity lies in making it happen. Before getting to that
>>> complexity, I don't really think of this as a "new idea". To me the
>>> description of gremlin-x is really just a GLV for Java. I mean -
>>> consider that gremlin-python (something we classify as a GLV) is
>>> basically "everything a python dev needs to build applications -
>>> nothing more/less" and that's pretty much what we want for java in
>>> gremlin-x. gremlin-x would basically be "everything a java dev needs
>>> to build applications - nothing more/less". So I'm not seeing much
>>> distinction there (nor the need for naming it "gremlin-x" really -
>>> seems to be as simple as "gremlin-java" to be in line with other GLVs
>>> we will have).
>> 
>> A… Okay, then there is no such thing as gremlin-core/
>> or gremlin-server/. Check out my packaging and subsequent reasoning:
>> 
>>gremlin-java/
>>  structure/
>>io/
>>  process/
>>remote/
>>  client/
>>  server/
>>language/
>>  graph/
>>machine/
>>  traversal/
>>steps/
>>strategies/
>>computer/
>>distributed/ **forthcoming**
>> 
>> 
>> And now, check out gremlin-python (as it currently stands):
>> 
>>gremlin-python/
>>  structure/
>>io/
>>  process/
>>remote/
>>  client/
>>language/
>>  graph/
>> 
>> 
>> Take home points:
>> 
>> 1. Gremlin-Java has a language, machine, server, and client
>> implementation.
>> 2. Gremlin-Python only has a language implementation and a remote
>> client implementation.
>> 3. remote/client is RemoteConnection and remote/server is RemoteServer
>> (making up that interface for now).
>> 4. We make more explicit the distinction between traversal machine and
>> traversal language and now you know 

[GitHub] tinkerpop pull request #510: TINKERPOP-1562 Migrate ScriptEngine-related cod...

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-1562 Migrate ScriptEngine-related code to gremlin-core

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

Apologies in advance - this is a fat, nasty PR and I doubt there would have 
been a way to break this up into smaller bits of work. Every change I made 
ended up creating new branches of stuff that needed to be touched. As it turns 
out `ScriptEngine` stuff was deeply nested into all areas of the code base and 
unraveling it all into a way that was non-breaking for 3.2.x was non-trivial.

The core of this work focuses on:

* Moving `ScriptEngine` and `GremlinPlugin`  related stuff out of 
gremlin-groovy down to gremlin-core. 
* Given the above change that meant:
** Taking each existing gremlin-groovy based `GremlinPlugin` (hadoop, 
giraph, gephi, etc) and developing a parallel plugin based on gremlin-core.
** Making it so that gremlin server/console could utilize either plugin 
type (gremlin-server does this through a separate configuration option in 
gremlin-server.yaml and the console does this through a system variable that 
you could add to gremlin.sh (`-Dplugins=v3d3`)
** Deprecating lots of odds and ends to allow me to move classes around. 
The deprecation approach was more tedious and leads to some dead code, but it 
was a nice way to evolve this change more slowly and intelligently. It also 
taught me that we should be more watchful of "public class" scope. If just a 
fraction of these classes that I deprecated (which no one probably uses anyway) 
had been package scope this work would have been much easier.

The testing for this body of work involved:

* `mvn clean install` with integration tests
* `docker/build.sh -t -i -n`
* `process-docs.sh`
* manual testing:
** every plugin in both versions 
** specific testing of the dependency grabber via `:install` for the 
console and `-i` in gremlin server

For the most part I didn't provide a lot of docs for this because I don't 
think we need to publish this for 3.2.x. These changes essentially just set the 
stage for use to use them in full in 3.3.0.  I'll do some separate smaller PRs 
for 3.3.0 work around this that will include doc updates as I remove the 
deprecated code I've created here.

VOTE +1

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

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

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

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


commit aca81c011c1d6e2df9be8a0b4085db6987a1839a
Author: Stephen Mallette 
Date:   2016-11-17T21:47:31Z

TINKERPOP-1562 Initial effort to deprecate ScriptEngines.

This opens up some options for how to move plugins up to gremlin-core (or 
deprecate them completely - not surehow that will flow yet). Anyway, this is a 
wip commit and a nice stop point.

commit d14005e8826f556882b0f0db64bec5ef4130e6e3
Author: Stephen Mallette 
Date:   2016-11-18T10:34:00Z

TINKERPOP-1562 More deprecation around methods on building GremlinExecutor 
that used ScriptEngines.

commit 4943f1217eaed23030f88a5bdf225eeda7baa1ff
Author: Stephen Mallette 
Date:   2016-11-21T12:36:40Z

TINKERPOP-1562 Add GreminServerGremlinModule for Gremlin Server specific 
imports

Allow use of instance() as a way for GremlinModules to be instantiated.

commit 8c7fada64e6d4d53b56ade84a0f4eb0acb49ecf8
Author: Stephen Mallette 
Date:   2016-11-21T12:54:35Z

TINKERPOP-1562 Add GremlinModule for Giraph.

commit f8fd64a650b4124eae89857ae1d7e66c05e00d5d
Author: Stephen Mallette 
Date:   2016-11-21T12:55:27Z

TINKERPOP-1562 Moved GremlinServerGremlinModule to standard directory 
structure

commit c182d1d47839c196a7592224fd83195b6a0a2993
Author: Stephen Mallette 
Date:   2016-11-21T15:56:21Z

TINKERPOP-1562 Deprecated GiraphGremlinPlugin.

commit a5f7daaf0ca90d4f3631c990720fbfd441e2e054
Author: Stephen Mallette 
Date:   2016-11-21T18:13:30Z

TINKERPOP-1562 Move RemoteAcceptor related stuff to gremlin-core.

commit 052f19f94a8534581226c9cdb6caebcc295d6820
Author: Stephen Mallette 
Date:   2016-11-21T18:15:02Z

TINKERPOP-1562 Renamed GremlinModule to GremlinPlugin in gremlin-core

commit d09cf9ce4ed42bc4da5d52438e896777ea5a667f
Author: Stephen Mallette 
Date:   2016-11-21T18:34:27Z

TINKERPOP-1562 Bring back GremlinModule and deprecate it.

GremlinModule was introduced in 3.2.3. Wasn't sure if GremlinModule was 
equal to a GremlinPlugin so I had 

Re: [TinkerPop] gremlin-x

[Jason Plurad]

> + I'll come back to this in the points below, but as a big fat general
question: how will we deal with transactions?

Bullseye. I'd add that assuming that TinkerGraph would be the "one true
TinkerPop graph" for gremlin-x testing, it needs to support transactions
which it doesn't do currently. Or introduce a new reference implementation
graph that does.

On Wed, Nov 30, 2016 at 4:58 PM, Stephen Mallette 
wrote:

> Added back "dev"
>
> I think we've tried a lot of things for TinkerPop 3 and that there are too
> many options for application development as well as an over-exposed API, so
> I like this direction, though a fair bit of complexity lies in making it
> happen. Before getting to that complexity, I don't really think of this as
> a "new idea". To me the description of gremlin-x is really just a GLV for
> Java. I mean - consider that gremlin-python (something we classify as a
> GLV) is basically "everything a python dev needs to build applications -
> nothing more/less" and that's pretty much what we want for java in
> gremlin-x. gremlin-x would basically be "everything a java dev needs to
> build applications - nothing more/less". So I'm not seeing much distinction
> there (nor the need for naming it "gremlin-x" really - seems to be as
> simple as "gremlin-java" to be in line with other GLVs we will have).
>
> Back to the "complexity" - and I think the questions in my mind that
> follow apply with or without this gremlin-x idea (they are general issues
> that just are faced by "remote" and GLVs):
>
> + I'll come back to this in the points below, but as a big fat general
> question: how will we deal with transactions?
> + What will be the nature of Graph.io() - in one sense i'd like to see
> that as something hidden as it is the source of a fair bit of confusion
> (i.e. someone trying to load a multi GB graphson file) but on the other
> hand it's convenient for small graphs - that story could be made better.
> Maybe Graph.io() being a part of "Graph" is hidden and only used by the
> test suite to load data into graph providers implementations for testing
> purposes. Of course, we will need our story in order for loading data in
> different formats if that isn't available (which I guess we need to do
> anyway).
> + Can remoting Gremlin bytecode cover everything that users currently do
> in embedded/local mode? The drawback with a remote traversal is that it is
> bound to a single transaction and you therefore lose some efficiency with
> certain graphs databases as logic with three traversals that might span a
> single transaction, for example, will be executed less efficiently as three
> different transaction refreshing a transaction cache each time. Maybe the
> server protocol needs to be session based? Maybe, going back to the first
> bullet i had, the transaction model needs to change so that its not bound
> to a single thread by default?
> + Related to the last point, is there an easy way to blend client code
> with server code? Meaning, if i have a body of complex logic right now, my
> only option is to submit a script. I think the ScriptEngine stuff should
> really just be used for those situations where you need a lambda. That's a
> nice, simple, easy-to-explain rule, whereas "do it if there is complex
> logic" is a bit more subjective (and potentially troublesome). How can GLVs
> get complex logic on the "server" (let's say the logic is written in java
> and available to gremlin server) so that it could be executed as part of
> some bytecode in any GLV?
> + It would be neat to see what kind of "server" changes we could make to
> optimize for bytecode. Right now we sorta tied bytecode execution into the
> same Gremlin Server execution pipeline as ScriptEngine processing. I think
> we could probably do better on that.
>
> Not sure there are any immediate answers to any of the above, but it's
> what I've been thinking about with respect to TinkerPop 3.3.0 lately.
>
>
>
> On Wed, Nov 30, 2016 at 1:11 PM, pieter-gmail 
> wrote:
>
>> Ok, if Sqlg just implements its own RemoteConnection and no need for an
>> additional server in the architecture then I am a lot less nervous about
>> gremlin-x.
>>
>> As an aside, Sqlg has its own peculiarities and optimization outside the
>> standard TinkerPop interface. Most providers will have such features. If
>> the graph is not exposed directly there will need to be some way to call
>> custom features. No idea how now, but still.
>>
>> E.g. for Sqlg the most used such feature is
>> SqlgGraph.tx().batchMode(batchModeType) but there are others. Index
>> management will be another. Without being able to access these features
>> too many benefits of choosing a particular provider will be lost.
>>
>> Cheers
>> Pieter
>>
>> On 30/11/2016 19:31, Marko Rodriguez wrote:
>> > Hi,
>> >
>> >> I generally recommend the exact opposite. Neo4j shines when embedded.
>> >
>> > And thats fine. There would simply be a 

Re: [TinkerPop] gremlin-x

[pieter-gmail]

Hi,

You say "v1.property(‘name’).value()" should never happen.
This is something we use all the time. Almost all the work we do is with
vertices and edges and is natural to call
element.property("something").isPresent(),
element.property("something").value(), element.property("something",
"somethingnew")

With this current train of thought will the use
Graph/Vertex/Edge/Property be discouraged or disappear?

Even as things stands now are you saying
vertex.property("something").value() should be replaced with
g.V(vertex).values("something")?

Thanks
Pieter


On 01/12/2016 16:43, Marko Rodriguez wrote:
> Hi,
>
>> I think we've tried a lot of things for TinkerPop 3 and that there
>> are too many options for application development as well as an
>> over-exposed API, so I like this direction, though a fair bit of
>> complexity lies in making it happen. Before getting to that
>> complexity, I don't really think of this as a "new idea". To me the
>> description of gremlin-x is really just a GLV for Java. I mean -
>> consider that gremlin-python (something we classify as a GLV) is
>> basically "everything a python dev needs to build applications -
>> nothing more/less" and that's pretty much what we want for java in
>> gremlin-x. gremlin-x would basically be "everything a java dev needs
>> to build applications - nothing more/less". So I'm not seeing much
>> distinction there (nor the need for naming it "gremlin-x" really -
>> seems to be as simple as "gremlin-java" to be in line with other GLVs
>> we will have).
>
> A… Okay, then there is no such thing as gremlin-core/
> or gremlin-server/. Check out my packaging and subsequent reasoning:
>
> gremlin-java/
>   structure/
> io/
>   process/
> remote/
>   client/
>   server/
> language/
>   graph/
> machine/
>   traversal/
> steps/
> strategies/
> computer/
> distributed/ **forthcoming**
>
>
> And now, check out gremlin-python (as it currently stands):
>
> gremlin-python/
>   structure/
> io/
>   process/
> remote/
>   client/
> language/
>   graph/
>
>
> Take home points:
>
> 1. Gremlin-Java has a language, machine, server, and client
> implementation.
> 2. Gremlin-Python only has a language implementation and a remote
> client implementation.
> 3. remote/client is RemoteConnection and remote/server is RemoteServer
> (making up that interface for now).
> 4. We make more explicit the distinction between traversal machine and
> traversal language and now you know which variants have machine
> implementations.
> 5. In the future, Gremlin-Python could have a machine implementation
> and then would be native for Python-based graph systems.
> - Thus, easy to grow TinkerPop into other languages.
>
> In this way, if you are a graph system provider with a system written
> in language XXX, then you come to TinkerPop and ask:
>
> 1. Does gremlin-XXX exist?
> 2. If so, does gremlin-XXX have a machine/ implementation?
> 3. If so, then implement gremlin-XXX structure API and you are now
> TinkerPop-enabled.
>
> In this way, if you are a graph system users with an application
> written in language XXX, then you come to TinkerPop and ask:
>
> 1. Does gremlin-XXX exist?
> 2. If so, does gremlin-XXX have a language/ implementation?
> 3. If so, then code in gremlin-XXX over any TinkerPop-enabled graph
> system.
>
> Finally, this makes making gremlin-test/ more language agnostic all
> the more important. If all the gremlin-XXX languages can be verified
> “natively” using gremlin-test/ (not via ScriptEngine emulation), then
> we are super cool.
>
> Finally, cause the last finally wasn’t enough, I would make it so
> gremlin-driver is in gremlin-java/ and I would keep gremlin-console/
> as its own thing because, while it is a Java-based REPL, it is
> language agnostic given the current work by Stephen to enable any
> ScriptEngine (not just Gremlin-Groovy) to be leveraged in Gremlin Console.
>
> Boom.
>
> Marko.
>
>
>>
>> Back to the "complexity" - and I think the questions in my mind that
>> follow apply with or without this gremlin-x idea (they are general
>> issues that just are faced by "remote" and GLVs):
>>
>> + I'll come back to this in the points below, but as a big fat
>> general question: how will we deal with transactions?
>> + What will be the nature of Graph.io () - in one
>> sense i'd like to see that as something hidden as it is the source of
>> a fair bit of confusion (i.e. someone trying to load a multi GB
>> graphson file) but on the other hand it's convenient for small graphs
>> - that story could be made better. Maybe Graph.io ()
>> being a part of "Graph" is hidden and only used by the test suite to
>> load data into graph providers implementations for testing purposes.
>> Of course, we will need our story in order for loading data in
>> 

Re: [TinkerPop] gremlin-x

[Marko Rodriguez]

Hi,

> I think we've tried a lot of things for TinkerPop 3 and that there are too 
> many options for application development as well as an over-exposed API, so I 
> like this direction, though a fair bit of complexity lies in making it 
> happen. Before getting to that complexity, I don't really think of this as a 
> "new idea". To me the description of gremlin-x is really just a GLV for Java. 
> I mean - consider that gremlin-python (something we classify as a GLV) is 
> basically "everything a python dev needs to build applications - nothing 
> more/less" and that's pretty much what we want for java in gremlin-x. 
> gremlin-x would basically be "everything a java dev needs to build 
> applications - nothing more/less". So I'm not seeing much distinction there 
> (nor the need for naming it "gremlin-x" really - seems to be as simple as 
> "gremlin-java" to be in line with other GLVs we will have).

A… Okay, then there is no such thing as gremlin-core/ or 
gremlin-server/. Check out my packaging and subsequent reasoning:

gremlin-java/
  structure/
io/
  process/
remote/
  client/
  server/
language/
  graph/
machine/
  traversal/
steps/
strategies/
computer/
distributed/ **forthcoming**

And now, check out gremlin-python (as it currently stands):

gremlin-python/
  structure/
io/
  process/
remote/
  client/
language/
  graph/

Take home points:

1. Gremlin-Java has a language, machine, server, and client 
implementation.
2. Gremlin-Python only has a language implementation and a remote 
client implementation.
3. remote/client is RemoteConnection and remote/server is RemoteServer 
(making up that interface for now).
4. We make more explicit the distinction between traversal machine and 
traversal language and now you know which variants have machine implementations.
5. In the future, Gremlin-Python could have a machine implementation 
and then would be native for Python-based graph systems.
- Thus, easy to grow TinkerPop into other languages.

In this way, if you are a graph system provider with a system written in 
language XXX, then you come to TinkerPop and ask:

1. Does gremlin-XXX exist?
2. If so, does gremlin-XXX have a machine/ implementation?
3. If so, then implement gremlin-XXX structure API and you are now 
TinkerPop-enabled.

In this way, if you are a graph system users with an application written in 
language XXX, then you come to TinkerPop and ask:

1. Does gremlin-XXX exist?
2. If so, does gremlin-XXX have a language/ implementation?
3. If so, then code in gremlin-XXX over any TinkerPop-enabled graph 
system.

Finally, this makes making gremlin-test/ more language agnostic all the more 
important. If all the gremlin-XXX languages can be verified “natively” using 
gremlin-test/ (not via ScriptEngine emulation), then we are super cool.

Finally, cause the last finally wasn’t enough, I would make it so 
gremlin-driver is in gremlin-java/ and I would keep gremlin-console/ as its own 
thing because, while it is a Java-based REPL, it is language agnostic given the 
current work by Stephen to enable any ScriptEngine (not just Gremlin-Groovy) to 
be leveraged in Gremlin Console.

Boom.

Marko.


> 
> Back to the "complexity" - and I think the questions in my mind that follow 
> apply with or without this gremlin-x idea (they are general issues that just 
> are faced by "remote" and GLVs):
> 
> + I'll come back to this in the points below, but as a big fat general 
> question: how will we deal with transactions?
> + What will be the nature of Graph.io() - in one sense i'd like to see that 
> as something hidden as it is the source of a fair bit of confusion (i.e. 
> someone trying to load a multi GB graphson file) but on the other hand it's 
> convenient for small graphs - that story could be made better. Maybe 
> Graph.io() being a part of "Graph" is hidden and only used by the test suite 
> to load data into graph providers implementations for testing purposes. Of 
> course, we will need our story in order for loading data in different formats 
> if that isn't available (which I guess we need to do anyway).
> + Can remoting Gremlin bytecode cover everything that users currently do in 
> embedded/local mode? The drawback with a remote traversal is that it is bound 
> to a single transaction and you therefore lose some efficiency with certain 
> graphs databases as logic with three traversals that might span a single 
> transaction, for example, will be executed less efficiently as three 
> different transaction refreshing a transaction cache each time. Maybe the 
> server protocol needs to be session based? Maybe, going back to the first 
> bullet i had, the transaction model needs to change so that its not bound to 
> a single thread by default?  
> + Related to the last point, is there an easy 

[jira] [Closed] (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:all-tabpanel
 ]

Marko A. Rodriguez closed TINKERPOP-1573.
-
   Resolution: Fixed
Fix Version/s: 3.2.4

> 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
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.4
>
>
> {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 #507: TINKERPOP-1573: Bindings don't work in coalesce

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
Yea, go ahead and merge it. One day I'll be bored and rewrite this stuff. 
Maybe around Xmas.


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

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
I know it sucks. I don't like this any more than you do. Here is the saving 
grace -- if someone comes up with a better solution, there are only two classes 
we need to tweak (`Bytecode` and `Bindings`). `Bindings` (besides as a 
singleton) are never accessed outside of these two classes. Moreover, most of 
the `Bindings` methods are `protected` and thus, not exposed to users. Only 
`of` is exposed.

I'll merge and perhaps someone down the road comes up with the better 
solution. ?.


> 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
>Assignee: Marko A. Rodriguez
>
> {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 #507: TINKERPOP-1573: Bindings don't work in coalesce

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
I know it sucks. I don't like this any more than you do. Here is the saving 
grace -- if someone comes up with a better solution, there are only two classes 
we need to tweak (`Bytecode` and `Bindings`). `Bindings` (besides as a 
singleton) are never accessed outside of these two classes. Moreover, most of 
the `Bindings` methods are `protected` and thus, not exposed to users. Only 
`of` is exposed.

I'll merge and perhaps someone down the road comes up with the better 
solution. ?.


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

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
Fine. I still think the code sucks (you know, usually I'm dazzled by the 
beauty of the code you write, but this time, mn...). Anyways..

VOTE: +1


> 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
>Assignee: Marko A. Rodriguez
>
> {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-1578) Support writable distributed graphs using spark as the underlying engine

[Marko A. Rodriguez (JIRA)]

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

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

Can you generalize to make work for {{GraphComputer}} and not just 
{{SparkGraphComputer}} ? This way its not a Spark-specific thing?

> Support writable distributed graphs using spark as the underlying engine
> 
>
> Key: TINKERPOP-1578
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1578
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dovid Kopel
>




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

[jira] [Commented] (TINKERPOP-1539) Create a ComplexTraversalTest with crazy nested gnarly traversals.

[Marko A. Rodriguez (JIRA)]

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

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

As a side, I do think we should add a new toy graph. One that has the following:

1. A Self-loop.
2. A vertex with no edges.
3. Edges of the same label with a different number of properties.

Perhaps [~dkuppitz] you could come up with a new toy graph data structure to 
add to our collection while doing this ticket?


> Create a ComplexTraversalTest with crazy nested gnarly traversals.
> --
>
> Key: TINKERPOP-1539
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1539
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, test-suite
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> Our {{ProcessSuite}} has numerous tests verifying the semantics of the 
> various steps. Unfortunately, these tests are on simple traversals focused on 
> exposing the step in question in isolation.
> It would be good to add {{ComplexTraversalTest}} to the {{ProcessSuite}} 
> which has traversals over the Grateful Dead graph (for complexity reasons) 
> doing:
> 1. Numerous nests.
> 2. Match/Select/Where complexities.
> 3. Global side-effect access and unrolling and injecting.
> 4. ... just a bunch of nasty stuff.
> This will give us much more confidence as we add more strategies and 
> potentially, mess up our algebra which isn't exposed by the simple 
> "flat'-traversals we current test with.
> [~dkuppitz] --- would you be interested in doing this?



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

[jira] [Updated] (TINKERPOP-1578) Support writable distributed graphs using spark as the underlying engine

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1578:

Affects Version/s: 3.2.3
  Component/s: hadoop
   Issue Type: Improvement  (was: New Feature)

> Support writable distributed graphs using spark as the underlying engine
> 
>
> Key: TINKERPOP-1578
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1578
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dovid Kopel
>




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

[jira] [Commented] (TINKERPOP-1539) Create a ComplexTraversalTest with crazy nested gnarly traversals.

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1539:
-

I sense that we could use some additional test data. In writing recipes, I've 
found it difficult many times to express certain concepts into our toy graphs. 
I can imagine that one per test might not be crazy to expect, though hopefully 
some re-use would be possible.

> Create a ComplexTraversalTest with crazy nested gnarly traversals.
> --
>
> Key: TINKERPOP-1539
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1539
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, test-suite
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> Our {{ProcessSuite}} has numerous tests verifying the semantics of the 
> various steps. Unfortunately, these tests are on simple traversals focused on 
> exposing the step in question in isolation.
> It would be good to add {{ComplexTraversalTest}} to the {{ProcessSuite}} 
> which has traversals over the Grateful Dead graph (for complexity reasons) 
> doing:
> 1. Numerous nests.
> 2. Match/Select/Where complexities.
> 3. Global side-effect access and unrolling and injecting.
> 4. ... just a bunch of nasty stuff.
> This will give us much more confidence as we add more strategies and 
> potentially, mess up our algebra which isn't exposed by the simple 
> "flat'-traversals we current test with.
> [~dkuppitz] --- would you be interested in doing this?



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

[jira] [Commented] (TINKERPOP-1539) Create a ComplexTraversalTest with crazy nested gnarly traversals.

[Marko A. Rodriguez (JIRA)]

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

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

The problem with creating new graphs in the test is that if the underlying 
graph system doesn't support {{Graph.Features.supportsAddingVertices()}} (e.g. 
Spark/Hadoop/Giraph), then the test would be skipped. So, I  think its okay for 
a couple of tests if need be, but if you can get the desired complexity over 
the Grateful Dead graph, that would be best.

> Create a ComplexTraversalTest with crazy nested gnarly traversals.
> --
>
> Key: TINKERPOP-1539
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1539
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, test-suite
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> Our {{ProcessSuite}} has numerous tests verifying the semantics of the 
> various steps. Unfortunately, these tests are on simple traversals focused on 
> exposing the step in question in isolation.
> It would be good to add {{ComplexTraversalTest}} to the {{ProcessSuite}} 
> which has traversals over the Grateful Dead graph (for complexity reasons) 
> doing:
> 1. Numerous nests.
> 2. Match/Select/Where complexities.
> 3. Global side-effect access and unrolling and injecting.
> 4. ... just a bunch of nasty stuff.
> This will give us much more confidence as we add more strategies and 
> potentially, mess up our algebra which isn't exposed by the simple 
> "flat'-traversals we current test with.
> [~dkuppitz] --- would you be interested in doing this?



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