date:20161130

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

2016-11-30 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz commented on TINKERPOP-1539:
---

[~okram] Do you prefer to use the good old toy graphs for these tests or should 
we create custom graphs (in the worst case one per test)? I would prefer if we 
don't limit ourselves to the toy graphs (it's actually just the GD graph when 
we talk about complex queries). Every now and then I end up writing real 
complex queries on the mailing list; these queries require graphs with certain 
structures that we mostly won't find in our toy graphs.

> 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 issue #507: TINKERPOP-1573: Bindings don't work in coalesce

2016-11-30 Thread dkuppitz

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
Okay, I see what you're saying. I fixed that and here's another version:
https://gist.github.com/dkuppitz/47bae08ab19c848f663d95c7213da26b

What I'm worried about in your implementation is the `MAP.get()` in every 
method. Look into the `ThreadLocal` implementation how nasty this call can get.


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

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
@dkuppitz  --- while your model looks more "natural," the problem is that 
we will create a `Bindings` instance in `ThreadLocal` for every `Bytecode` 
creation. Given that `Bindings` are rare (especially given that they are only 
useful for ScriptEngine languages (and thus only when lambdas are used) -- not 
Gremlin-Java), then with the model I have, we don't create a bunch of 
`ThreadLocal` values for "no reason."


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

2016-11-30 Thread okram

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/509
  
In Gremlin-Java, those methods do the following:

```
public static  GraphTraversal start() {
return new DefaultGraphTraversal<>();
}

public static  GraphTraversal __(final A... starts) {
return inject(starts);
}
```

Perhaps just hardcode those methods in Python `__` to do the analogous 
behavior.
Also can you add some test cases? 


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

2016-11-30 Thread Stephen Mallette

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 EmbeddedRemoteConnection which
> > is basically just a proxy that does nothing. No need for server stuff.
> >
> >> Sqlg already works of databases that is designed for remote access.
> >
> > And yes, thats where a full fledged RemoteConnection (like
> > GremlinServer’s) is needed for marshaling data over a network.
> >
> >> Wrapping that with yet another server is an unnecessary complication.
> >
> > Its not about GremlinServer so much as its about RemoteConnection. If
> > Sqlg has their own RemoteConnection implementation, then it uses that.
> > Likewise, Neo4jServer could provide

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

2016-11-30 Thread Dovid Kopel (JIRA)


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

Dovid Kopel commented on TINKERPOP-1578:


https://github.com/dovidkopel/tinkerpop/tree/TINKERPOP-1578

I spent around two days and have basic functionality. I did not make a pull 
request yet. I haven't created ample tests and coverage.

I intentionally abstracted the RDD storage from the graph to allow for future 
changes.

I had fully functional traversals using the built-in strategies.

Please let me know what you think so far. If you think this is a reasonable 
approach I can clean things up and make an official pull request.

> 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: New Feature
>Reporter: Dovid Kopel
>




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

[GitHub] tinkerpop pull request #509: TINKERPOP-1576 gremlin-python calls non-existen...

2016-11-30 Thread FlorianHockmann

GitHub user FlorianHockmann opened a pull request:

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

TINKERPOP-1576 gremlin-python calls non-existent methods

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

This removes the methods `__.__()` and `__.start()` from gremlin-python as 
they called the respective methods on `GraphTraversal` which doesn't have those 
methods.

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

$ git pull https://github.com/FlorianHockmann/tinkerpop TINKERPOP-1576

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

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


commit 94cdc2adfeab6e2a868b9ccb273e8336cad82144
Author: Florian Hockmann 
Date:   2016-11-30T20:08:05Z

Fix calling of non-existing methods




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

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
I don't like the implementation of `Bindings`. Suggestion for an improved 
implementation: 
https://gist.github.com/dkuppitz/8bd896d639c3fd8fc27fa33f832e68ef


> 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

2016-11-30 Thread dkuppitz

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
I don't like the implementation of `Bindings`. Suggestion for an improved 
implementation: 
https://gist.github.com/dkuppitz/8bd896d639c3fd8fc27fa33f832e68ef


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

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/tinkerpop/pull/508#discussion_r90306572
  
--- Diff: docker/resources/groovy/grapeConfig.xml ---
@@ -1,15 +1,22 @@
 
   
+  
+  
+  
+
+  
   
 
+  
+
+
+  
   
 
 
   
-  http://repository.codehaus.org/; 
m2compatible="true"/>
-  http://central.maven.org/maven2/; 
m2compatible="true"/>
-  http://download.java.net/maven/2/; 
m2compatible="true"/>
-  http://obelix.ics.uci.edu/nexus/content/groups/hyracks-public-releases/; 
m2compatible="true"/>
--- End diff --

that is most excellent - guess we never noticed that before. i will make a 
note to backport to tp31.


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

2016-11-30 Thread spmallette

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

https://github.com/apache/tinkerpop/pull/508#discussion_r90306572
  
--- Diff: docker/resources/groovy/grapeConfig.xml ---
@@ -1,15 +1,22 @@
 
   
+  
+  
+  
+
+  
   
 
+  
+
+
+  
   
 
 
   
-  http://repository.codehaus.org/; 
m2compatible="true"/>
-  http://central.maven.org/maven2/; 
m2compatible="true"/>
-  http://download.java.net/maven/2/; 
m2compatible="true"/>
-  http://obelix.ics.uci.edu/nexus/content/groups/hyracks-public-releases/; 
m2compatible="true"/>
--- End diff --

that is most excellent - guess we never noticed that before. i will make a 
note to backport to tp31.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TINKERPOP-1577) Provide support for Python3 or Python2 in the Docker builds.

2016-11-30 Thread Marko A. Rodriguez (JIRA)

Marko A. Rodriguez created TINKERPOP-1577:
-

 Summary: Provide support for Python3 or Python2 in the Docker 
builds.
 Key: TINKERPOP-1577
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1577
 Project: TinkerPop
  Issue Type: Improvement
  Components: build-release
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez
Assignee: Daniel Kuppitz


We need to make sure that Python2 and Python3 are both supported by 
Gremlin-Python. Thus, our docker build/test stuff should test both versions of 
Python.



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

[jira] [Updated] (TINKERPOP-1561) gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5

2016-11-30 Thread Marko A. Rodriguez (JIRA)


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

Marko A. Rodriguez updated TINKERPOP-1561:
--
Assignee: David M. Brown

> gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5
> ---
>
> Key: TINKERPOP-1561
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1561
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.3
> Environment: Python 3.5
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.2.4
>
>
> Because {{long}} doesn't exist in Python 3, we created a simple wrapper that 
> inherits from {{int}} to fill the void. After the last changes to the 
> gremlin-python {{graphson}} module, this inheritance causes our longs to be 
> serialized as {{Int32}}. For example:
> {code}
> from gremlin_python.statics import long
> from gremlin_python.structure.io.graphson import GraphSONWriter
> writer = GraphSONWriter()
> writer.toDict(1)
> {'@type': 'g:Int32', '@value': 1}
> writer.toDict(long(1))
> {'@type': 'g:Int32', '@value': 1}
> {code}
> This should be an easy fix. As far as I can see there are two main approaches:
> 1. Combine the {{Int64IO}} and {{Int32IO}} classes and perform an instance 
> check for long in the {{dictify()}} method; or,
> 2. Implement a {{long}} type that doesn't inherit from {{int}}. Here we would 
> probably want to define a variety of methods so our {{long}} emulates 
> Python's numeric object.
> Does anyone have an opinion on a preferred approach? I would probably go with 
> the first approach, but either could work.



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

[jira] [Closed] (TINKERPOP-1561) gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5

2016-11-30 Thread Marko A. Rodriguez (JIRA)


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

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

> gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5
> ---
>
> Key: TINKERPOP-1561
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1561
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.3
> Environment: Python 3.5
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.2.4
>
>
> Because {{long}} doesn't exist in Python 3, we created a simple wrapper that 
> inherits from {{int}} to fill the void. After the last changes to the 
> gremlin-python {{graphson}} module, this inheritance causes our longs to be 
> serialized as {{Int32}}. For example:
> {code}
> from gremlin_python.statics import long
> from gremlin_python.structure.io.graphson import GraphSONWriter
> writer = GraphSONWriter()
> writer.toDict(1)
> {'@type': 'g:Int32', '@value': 1}
> writer.toDict(long(1))
> {'@type': 'g:Int32', '@value': 1}
> {code}
> This should be an easy fix. As far as I can see there are two main approaches:
> 1. Combine the {{Int64IO}} and {{Int32IO}} classes and perform an instance 
> check for long in the {{dictify()}} method; or,
> 2. Implement a {{long}} type that doesn't inherit from {{int}}. Here we would 
> probably want to define a variety of methods so our {{long}} emulates 
> Python's numeric object.
> Does anyone have an opinion on a preferred approach? I would probably go with 
> the first approach, but either could work.



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

[jira] [Commented] (TINKERPOP-1561) gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

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


> gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5
> ---
>
> Key: TINKERPOP-1561
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1561
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.3
> Environment: Python 3.5
>Reporter: David M. Brown
>
> Because {{long}} doesn't exist in Python 3, we created a simple wrapper that 
> inherits from {{int}} to fill the void. After the last changes to the 
> gremlin-python {{graphson}} module, this inheritance causes our longs to be 
> serialized as {{Int32}}. For example:
> {code}
> from gremlin_python.statics import long
> from gremlin_python.structure.io.graphson import GraphSONWriter
> writer = GraphSONWriter()
> writer.toDict(1)
> {'@type': 'g:Int32', '@value': 1}
> writer.toDict(long(1))
> {'@type': 'g:Int32', '@value': 1}
> {code}
> This should be an easy fix. As far as I can see there are two main approaches:
> 1. Combine the {{Int64IO}} and {{Int32IO}} classes and perform an instance 
> check for long in the {{dictify()}} method; or,
> 2. Implement a {{long}} type that doesn't inherit from {{int}}. Here we would 
> probably want to define a variety of methods so our {{long}} emulates 
> Python's numeric object.
> Does anyone have an opinion on a preferred approach? I would probably go with 
> the first approach, but either could work.



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

[GitHub] tinkerpop pull request #505: TINKERPOP-1561 gremiln-python GraphSONWriter do...

2016-11-30 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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-1561) gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user spmallette commented on the issue:

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


> gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5
> ---
>
> Key: TINKERPOP-1561
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1561
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.3
> Environment: Python 3.5
>Reporter: David M. Brown
>
> Because {{long}} doesn't exist in Python 3, we created a simple wrapper that 
> inherits from {{int}} to fill the void. After the last changes to the 
> gremlin-python {{graphson}} module, this inheritance causes our longs to be 
> serialized as {{Int32}}. For example:
> {code}
> from gremlin_python.statics import long
> from gremlin_python.structure.io.graphson import GraphSONWriter
> writer = GraphSONWriter()
> writer.toDict(1)
> {'@type': 'g:Int32', '@value': 1}
> writer.toDict(long(1))
> {'@type': 'g:Int32', '@value': 1}
> {code}
> This should be an easy fix. As far as I can see there are two main approaches:
> 1. Combine the {{Int64IO}} and {{Int32IO}} classes and perform an instance 
> check for long in the {{dictify()}} method; or,
> 2. Implement a {{long}} type that doesn't inherit from {{int}}. Here we would 
> probably want to define a variety of methods so our {{long}} emulates 
> Python's numeric object.
> Does anyone have an opinion on a preferred approach? I would probably go with 
> the first approach, but either could work.



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

[GitHub] tinkerpop issue #505: TINKERPOP-1561 gremiln-python GraphSONWriter doesn't p...

2016-11-30 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/505
  
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-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

2016-11-30 Thread Marko A. Rodriguez (JIRA)


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

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

Huh. Thats a good idea. Yea, right now its hardcoded to just use 
{{DetachedXXX}}. It would be cool if GraphSONSerializers took a {{Factory}} for 
creating the detachments -- whether {{DeatchedXXX}} or {{ReferenceXXX}} or .. 
someting else down the line -- e.g. {{StarXXX}}.

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

Re: [TinkerPop] gremlin-x

2016-11-30 Thread Marko Rodriguez

Hi,

> I generally recommend the exact opposite. Neo4j shines when embedded.

And thats fine. There would simply be a EmbeddedRemoteConnection which is 
basically just a proxy that does nothing. No need for server stuff.

> Sqlg already works of databases that is designed for remote access.

And yes, thats where a full fledged RemoteConnection (like GremlinServer’s) is 
needed for marshaling data over a network.

> Wrapping that with yet another server is an unnecessary complication.

Its not about GremlinServer so much as its about RemoteConnection. If Sqlg has 
their own RemoteConnection implementation, then it uses that. Likewise, 
Neo4jServer could provide its own RemoteConnection implementation and thus, no 
need for GremlinServer. 

> (Not having used it I do not know the usability or performance impact,
> however being another layer it can only degrade performance and
> complexity).

For embedded, its an implementation that just returns the traversal as was 
submitted.
For remote, its as it is now. You have to send the bytecode over the network 
and stream back results.

> Further because Sqlg already works of a remote database it supports many
> jvm's directly accessing the same graph. I imagine other providers could
> have the same feature.

This is fine with RemoteConnection. What is “not fine” (the reason for 
gremlin-x) is to make it so users can’t talk with the Graph object. That is a 
Java thing and should not be exposed to users. More specifically, that is a 
Gremlin traversal machine <-> graph system provider interface. Users only 
interact with a RemoteConnection implementation.

> So gremlin-x is fine but it is not the obvious best choice for all
> architectures.

I was shootin’ this idea around DSEGraph people and Bob was like: “pfff…where 
was this idea 4 years ago. Everyone is already addicting to sending a 
Gremlin-Groovy script over the network and getting a ResultSet back.”

> All the above is for happy java devs.

Again, the purpose is the constrain Java developers too. Things like this 
should never happen:

v1.property(‘name’).value()
v1.edges(OUT).next()
cluster.submit(“1+2”)
graph = GraphFactory.open(...)
graph.io (gryo()).readGraph(‘data/blah.gryo’)

It should be:

g.V(1).values(‘name’)
g.V(1).outE().next()
g.inject(1,2).sum()
g.withRemote(config)
// hmmm… don’t know about the last one. 

See ya,
Marko.

> Cheers
> Pieter
> 
> On 30/11/2016 16:06, Marko Rodriguez wrote:
>> Hello,
>> 
>> I think TinkerPop has too many ways of doing things. For instance:
>> 
>>  1. Users can use graph traversal or interact with vertex/edge/etc. Java 
>> objects directly.
>>  2. Users can interact with the graph system embedded (via the Graph 
>> object) or remotely (via RemoteConnection).
>>  3. Users can submit Gremlin string scripts or submit Gremlin bytecode 
>> to GremlinServer (along with other REST/etc. type capabilities possible).
>>  4. Users can use GraphML, GraphSON, or Gryo for serialization.
>>  5. Users can use Gremlin-Groovy, Gremlin-Java, Gremlin-Python, 
>> Gremlin-Scala, etc.
>>  6. Users can use Titan, Neo4j, OrientDB, etc.
>> 
>> I think we should create a module called gremlin-x/ which is the most 
>> simplified, concise, recommended way to use TinkerPop. In correspondence to 
>> the itemization above:
>> 
>>  1. Users can only use graph traversal. All returned elements are 
>> ReferenceElements.
>>  2. Users can only interact with the graph remotely (where remote may 
>> just be a localhost connection — in-memory proxy (e.g. for TinkerGraph)).
>>  3. Users can only submit Gremlin bytecode to GremlinServer (thus, only 
>> RemoteConnection can be used). No more security issues, no more 
>> uninterruptible scripts, etc.
>>  4. Users can only use GraphSON as its language agnostic.
>>  5. Users can use any Gremlin language variant as long is generates 
>> Gremlin bytecode.
>>  6. Users can use any graph system provider as long as it has a 
>> RemoteConnection exposed (where the provider can simply leverage 
>> GremlinServer).
>> 
>> Finally, we should create a separate documentation called gremlin-x.asciidoc 
>> which is small and discusses the rationale for the constrained specification 
>> and references the core reference docs accordingly. For instance, no need to 
>> have all the step examples re-written.
>> 
>> I believe that this will make it easier for users to say the following:
>> 
>>  “Okay, I get it. Open a RemoteConnection from a GraphTraversalSource 
>> (g.withRemote(...)) and spawn traversals and get back results. Thats it?! 
>> Easy peasy lemon squeezy.” 
>> 
>> I believe that this will make it easier for system developers to say the 
>> following:
>> 
>>  “We can cover 95% of use cases by simply exposing a RemoteConnection. 
>> Thats it?! Easy peasy lemon squeezy."
>> 
>> In general, this model looks at TinkerPop as a “remote database system” 
>> where users submit “queries” and get back

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

2016-11-30 Thread Kevin Gallardo (JIRA)


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

Kevin Gallardo commented on TINKERPOP-1565:
---

But it wouldn't be a ReferenceXXX element that you deserialize when you use 
{{getOrDefault()}} right? It would just be an empty DetachedXXX, that's the 
part I struggle to understand. With the additional module, you could say 
"Everything I deserialize is a DetachedXXX OR everything is ReferenceXXX". And 
so according to the module used, on the serialization either everything is 
lengthy and deserialized as Detached, or less lengthy and deserialized as 
Reference. Also I think it would be useful (at least for me) to define what are 
the fields considered sufficient for Reference elements

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

2016-11-30 Thread Florian Hockmann (JIRA)

Florian Hockmann created TINKERPOP-1576:
---

 Summary: 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.3, 3.2.2
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] [Closed] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

2016-11-30 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz closed TINKERPOP-1483.
-
   Resolution: Fixed
Fix Version/s: 3.3.0

> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0
>
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[jira] [Assigned] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

2016-11-30 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz reassigned TINKERPOP-1483:
-

Assignee: Daniel Kuppitz

> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>Assignee: Daniel Kuppitz
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

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


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[GitHub] tinkerpop pull request #446: TINKERPOP-1483: valueMap should always return s...

2016-11-30 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Looked through the code, did some manual test - all good.

VOTE: +1

Gonna merge it in a few.


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...

2016-11-30 Thread dkuppitz

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Looked through the code, did some manual test - all good.

VOTE: +1

Gonna merge it in a few.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TINKERPOP-1575) Neo4j indicies not used when multiple labels are searched for

2016-11-30 Thread Branden Moore (JIRA)

Branden Moore created TINKERPOP-1575:


 Summary: Neo4j indicies not used when multiple labels are searched 
for
 Key: TINKERPOP-1575
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1575
 Project: TinkerPop
  Issue Type: Improvement
  Components: neo4j
Affects Versions: 3.2.3
Reporter: Branden Moore
Priority: Minor


When using a Neo4j-based graph, indicies are not used when more than one label 
is searched for.

{noformat}
gremlin> g.V().hasLabel("alpha").has("myProp", 10)
Final Traversal  [Neo4jGraphStep(vertex,[~label.eq(alpha),myProp.eq(10)]))]
gremlin> g.V().hasLabel("alpha", "beta").has("myProp", 10)
Final Traversal  
[Neo4jGraphStep(vertex,[~label.within(alpha,beta),myProp.eq(10)]))]
{noformat}



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

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

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
`docker/build.sh -t -i -n` passes.

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)

[GitHub] tinkerpop issue #507: TINKERPOP-1573: Bindings don't work in coalesce

2016-11-30 Thread robertdale

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/507
  
`docker/build.sh -t -i -n` passes.

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

2016-11-30 Thread Marko A. Rodriguez (JIRA)


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

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

When Gremlin-Python gets back a {{g:Property}} and creates a {{Property.py}} 
object, that {{Property.py}} object should have sufficient information to 
support re-attaching to the source graph. For instance:

{code}
>>> vertex = g.V().out('created').next()
v[4]
>>> g.V(vertex).in_().count()
3
{code}

This sort of attach-ability is necessary for all elements: Vertex, Edge, 
VertexProperty, Property.

Regarding "detached" vs. "reference" ... The JSON serialization specified has 
enough information to created "detached elements" though, through the use of 
{{getOrDefault()}}-style semantics in deserialization, it is possible to only 
transmit what is sufficient to create a "reference element."




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

2016-11-30 Thread Marko A. Rodriguez (JIRA)


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

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

For 3.3.0 we should get rid of the concept of GraphSON 2.0 untyped 
(non-embedded types). This distinction is a complication and in fact, shouldn't 
really be used ever given the GLV direction with GraphSON and serialization 
format. It should all be typed GraphSON 2.0.

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

gremlin-x

2016-11-30 Thread Marko Rodriguez

Hello,

I think TinkerPop has too many ways of doing things. For instance:

1. Users can use graph traversal or interact with vertex/edge/etc. Java 
objects directly.
2. Users can interact with the graph system embedded (via the Graph 
object) or remotely (via RemoteConnection).
3. Users can submit Gremlin string scripts or submit Gremlin bytecode 
to GremlinServer (along with other REST/etc. type capabilities possible).
4. Users can use GraphML, GraphSON, or Gryo for serialization.
5. Users can use Gremlin-Groovy, Gremlin-Java, Gremlin-Python, 
Gremlin-Scala, etc.
6. Users can use Titan, Neo4j, OrientDB, etc.

I think we should create a module called gremlin-x/ which is the most 
simplified, concise, recommended way to use TinkerPop. In correspondence to the 
itemization above:

1. Users can only use graph traversal. All returned elements are 
ReferenceElements.
2. Users can only interact with the graph remotely (where remote may 
just be a localhost connection — in-memory proxy (e.g. for TinkerGraph)).
3. Users can only submit Gremlin bytecode to GremlinServer (thus, only 
RemoteConnection can be used). No more security issues, no more uninterruptible 
scripts, etc.
4. Users can only use GraphSON as its language agnostic.
5. Users can use any Gremlin language variant as long is generates 
Gremlin bytecode.
6. Users can use any graph system provider as long as it has a 
RemoteConnection exposed (where the provider can simply leverage GremlinServer).

Finally, we should create a separate documentation called gremlin-x.asciidoc 
which is small and discusses the rationale for the constrained specification 
and references the core reference docs accordingly. For instance, no need to 
have all the step examples re-written.

I believe that this will make it easier for users to say the following:

“Okay, I get it. Open a RemoteConnection from a GraphTraversalSource 
(g.withRemote(...)) and spawn traversals and get back results. Thats it?! Easy 
peasy lemon squeezy.” 

I believe that this will make it easier for system developers to say the 
following:

“We can cover 95% of use cases by simply exposing a RemoteConnection. 
Thats it?! Easy peasy lemon squeezy."

In general, this model looks at TinkerPop as a “remote database system” where 
users submit “queries” and get back “results.” That is it. Nothing 
Java-specific, nothing with executing arbitrary scripts remotely, nothing with 
REST, nothing with embedded (at least from a look-and-feel perspective), etc.

Thoughts?,
Marko.

http://markorodriguez.com

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Hold on, I've been busy with other stuff. I will look into this PR today.


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[jira] [Comment Edited] (TINKERPOP-1564) Distributed OLTP Traversals and the Introduction of Partition Concept

2016-11-30 Thread Marko A. Rodriguez (JIRA)


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

Marko A. Rodriguez edited comment on TINKERPOP-1564 at 11/30/16 1:05 PM:
-

In Akka, remoting uses the following URI scheme:

{code}
akka://@:/
{code}

Mapping this to TinkerPop:

{code}
akka://traversals@88.88.88.88:/f6609a45-4e76-4fbd-b5a2-073490bb5081/2435
   traverser routing system
  Partition.getLocation()
  Port is configurable
Traversal UUID
 Step ID
{code}

Thus, we have a URI schema.


was (Author: okram):
In Akka, remoting uses the following URI scheme:

{code}
akka://@:/
{code}

Mapping this to TinkerPop:

{code}
akka://traversals@88.88.88.88:/f6609a45-4e76-4fbd-b5a2-073490bb5081/2435
   traverser routing system
  Partition.getLocation()
Port is configurable
  Traversal UUID

  Step ID
{code}

Thus, we have a URI schema.

> Distributed OLTP Traversals and the Introduction of Partition Concept
> -
>
> Key: TINKERPOP-1564
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1564
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, process, server
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>
> This proposal unifies OLTP and OLAP into a single framework that removes the 
> need for OLAP {{GraphComputer}} by introducing distributed, data local 
> processing to OLTP. In essence, this is a proposal for a step-by-step query 
> routing framework within {{Traversal}}. This proposal can work across 
> machines in a cluster, threads on a machine, or in a hierarchical fashion 
> machines The example presented will discuss distribution across 
> machines in a cluster as its the most complicated scenario.
> Currently, an OLTP traversal executes at a particular machine (or thread) and 
> pulls vertex/edge/etc. data to it accordingly in order to solve the 
> traversal. In OLAP, the traversal is cloned and distributed to all machines 
> in the cluster and traversals communicate with one another by sending 
> {{Traversers}} (i.e. messages) between themselves ensuring data local 
> processing. Given recent advancements in GremlinServer and 
> {{RemoteTraversal}}, it is possible to add traverser routing to OLTP and 
> thus, effect the computational paradigm of Gremlin OLAP in Gremlin OLTP with 
> some added benefits not possible in Gremlin OLAP.
> Assume a 4 machine cluster and the following traversal:
> {code}
> g.V(1).out(‘knows’).has(‘age’,gt(20)).out(‘likes’).values(‘name’)
> {code}
> Every time there is a "walk" (adjacency), it is possible that the 
> {{Traverser}} is no longer accessing data local to the current machine. In 
> order to do data local query routing, every adjacency would feed into a 
> {{PartitionStep}}. The traversal above would be cloned (via {{Bytecode}} 
> distribution) across the cluster where "sibling" {{PartitionSteps}} would 
> have network access to one another using the same protocol of 
> {{RemoteConnection}} though called {{PartitionConnection}}. Thus, given the 4 
> node cluster example, the above traversal would be overlaid as below. Note 
> that {{partition()}} would not be a new step in the language, but simply 
> provided here to show where {{PartitionStrategy}} would insert 
> {{PartitionSteps}} into the traversal.
> {code}
> g.V(1).out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>|   |  
>^
> 
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>|   |  
>|
> 
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>|   |  
>|
> 
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
> {code}
> The top traversal is called the "master traversal" and the other three 
> "worker traversals." Note that this is identical to current Gremlin OLAP. 
> Now, the master traversal would be the traversal that is {{.next()}}'d for 
> results. So, when the "master traversal" is {{next()}}'d,

[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...

2016-11-30 Thread dkuppitz

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Hold on, I've been busy with other stuff. I will look into this PR today.


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

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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_r90227654
  
--- Diff: docker/resources/groovy/grapeConfig.xml ---
@@ -1,15 +1,22 @@
 
   
+  
+  
+  
+
+  
   
 
+  
+
+
+  
   
 
 
   
-  http://repository.codehaus.org/; 
m2compatible="true"/>
-  http://central.maven.org/maven2/; 
m2compatible="true"/>
-  http://download.java.net/maven/2/; 
m2compatible="true"/>
-  http://obelix.ics.uci.edu/nexus/content/groups/hyracks-public-releases/; 
m2compatible="true"/>
--- End diff --

Giraph is now available in Maven central, hence no reason to keep this 
exotic repository in the list: 
https://mvnrepository.com/artifact/org.apache.giraph


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

2016-11-30 Thread dkuppitz

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

https://github.com/apache/tinkerpop/pull/508#discussion_r90227654
  
--- Diff: docker/resources/groovy/grapeConfig.xml ---
@@ -1,15 +1,22 @@
 
   
+  
+  
+  
+
+  
   
 
+  
+
+
+  
   
 
 
   
-  http://repository.codehaus.org/; 
m2compatible="true"/>
-  http://central.maven.org/maven2/; 
m2compatible="true"/>
-  http://download.java.net/maven/2/; 
m2compatible="true"/>
-  http://obelix.ics.uci.edu/nexus/content/groups/hyracks-public-releases/; 
m2compatible="true"/>
--- End diff --

Giraph is now available in Maven central, hence no reason to keep this 
exotic repository in the list: 
https://mvnrepository.com/artifact/org.apache.giraph


---
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-1564) Distributed OLTP Traversals and the Introduction of Partition Concept

2016-11-30 Thread Marko A. Rodriguez (JIRA)


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

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

Huh. Thought. Each {{Step}} is an actor. Thus:

{code}
Partition (subgraph/machine bound)
  Traversal (thread bound)
Step (actor bound)
Traverser (message bound)
{code}

In this way, steps communicate with one another whether the next step for the 
traverser is local or remote. The question becomes, is it costly to message so 
much, where most messaging in a partitioned graph with step-actors will be 
local.



> Distributed OLTP Traversals and the Introduction of Partition Concept
> -
>
> Key: TINKERPOP-1564
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1564
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, process, server
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>
> This proposal unifies OLTP and OLAP into a single framework that removes the 
> need for OLAP {{GraphComputer}} by introducing distributed, data local 
> processing to OLTP. In essence, this is a proposal for a step-by-step query 
> routing framework within {{Traversal}}. This proposal can work across 
> machines in a cluster, threads on a machine, or in a hierarchical fashion 
> machines The example presented will discuss distribution across 
> machines in a cluster as its the most complicated scenario.
> Currently, an OLTP traversal executes at a particular machine (or thread) and 
> pulls vertex/edge/etc. data to it accordingly in order to solve the 
> traversal. In OLAP, the traversal is cloned and distributed to all machines 
> in the cluster and traversals communicate with one another by sending 
> {{Traversers}} (i.e. messages) between themselves ensuring data local 
> processing. Given recent advancements in GremlinServer and 
> {{RemoteTraversal}}, it is possible to add traverser routing to OLTP and 
> thus, effect the computational paradigm of Gremlin OLAP in Gremlin OLTP with 
> some added benefits not possible in Gremlin OLAP.
> Assume a 4 machine cluster and the following traversal:
> {code}
> g.V(1).out(‘knows’).has(‘age’,gt(20)).out(‘likes’).values(‘name’)
> {code}
> Every time there is a "walk" (adjacency), it is possible that the 
> {{Traverser}} is no longer accessing data local to the current machine. In 
> order to do data local query routing, every adjacency would feed into a 
> {{PartitionStep}}. The traversal above would be cloned (via {{Bytecode}} 
> distribution) across the cluster where "sibling" {{PartitionSteps}} would 
> have network access to one another using the same protocol of 
> {{RemoteConnection}} though called {{PartitionConnection}}. Thus, given the 4 
> node cluster example, the above traversal would be overlaid as below. Note 
> that {{partition()}} would not be a new step in the language, but simply 
> provided here to show where {{PartitionStrategy}} would insert 
> {{PartitionSteps}} into the traversal.
> {code}
> g.V(1).out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>|   |  
>^
> 
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>|   |  
>|
> 
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>|   |  
>|
> 
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
> {code}
> The top traversal is called the "master traversal" and the other three 
> "worker traversals." Note that this is identical to current Gremlin OLAP. 
> Now, the master traversal would be the traversal that is {{.next()}}'d for 
> results. So, when the "master traversal" is {{next()}}'d, {{g.V(1)}} will 
> fetch {{v[1]}} and then its outgoing knows-adjacencies. These adjacent 
> "reference vertices" would be fed into the first {{remote()}} and a "routing 
> algorithm" would determine where in the cluster the particular vertex's data 
> is. Thus, {{partition()}} ({{PartitionStep}}) serves as a router, pushing 
> {{Traversers}} local to the data. Finally, note that the final 
> {{PartitionSteps}} can only feed back to the "master traversal" for ultimate 
> aggregation and return to the user. 
> TinkerPop currently has all the structures in place to make this possible:
>   1. Encapsulation of computational metadata via {{Traverser}}.
>   2. The ability to detach {{Traversers}} and migrate/serialize them via 
>

[jira] [Commented] (TINKERPOP-1389) Support Spark 2.0.0

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/506
  
`docker/build.sh -t -i -n` succeeded.

VOTE: +1


> Support Spark 2.0.0
> ---
>
> Key: TINKERPOP-1389
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1389
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.1
>Reporter: Chen Xin Yu
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0
>
> Attachments: TINKERPOP-1389.patch
>
>
> Spark 2.0.0 was released:
> http://spark.apache.org/news/spark-2-0-0-released.html
> There are lots of improvement and changes compared to 1.6.1, we should better 
> bump to it for TinkerPop.



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

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

2016-11-30 Thread dkuppitz

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/506
  
`docker/build.sh -t -i -n` succeeded.

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-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
This is looking really good. We need one more VOTE.


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

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

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/508
  
Building world `docker/build.sh -t -i -n -d ` passes.
Building docs only `docker/build.sh -d ` passes.
Skimmed reference docs through browser.

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

2016-11-30 Thread robertdale

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/508
  
Building world `docker/build.sh -t -i -n -d ` passes.
Building docs only `docker/build.sh -d ` passes.
Skimmed reference docs through browser.

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-1389) Support Spark 2.0.0

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/506
  
```
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 04:20 h
[INFO] Finished at: 2016-11-29T23:00:51-07:00
[INFO] Final Memory: 148M/1743M
[INFO] 

```


> Support Spark 2.0.0
> ---
>
> Key: TINKERPOP-1389
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1389
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.1
>Reporter: Chen Xin Yu
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0
>
> Attachments: TINKERPOP-1389.patch
>
>
> Spark 2.0.0 was released:
> http://spark.apache.org/news/spark-2-0-0-released.html
> There are lots of improvement and changes compared to 1.6.1, we should better 
> bump to it for TinkerPop.



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

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

2016-11-30 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/tinkerpop/pull/508#discussion_r90213680
  
--- Diff: docker/resources/groovy/grapeConfig.xml ---
@@ -1,15 +1,22 @@
 
   
+  
+  
+  
+
+  
   
 
+  
+
+
+  
   
 
 
   
-  http://repository.codehaus.org/; 
m2compatible="true"/>
-  http://central.maven.org/maven2/; 
m2compatible="true"/>
-  http://download.java.net/maven/2/; 
m2compatible="true"/>
-  http://obelix.ics.uci.edu/nexus/content/groups/hyracks-public-releases/; 
m2compatible="true"/>
--- End diff --

maybe you learned something new about grape, but why does this work without 
these entries? if giraph isn't in the local /.m2 or ./groovy then how will it 
get those dependencies?


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

2016-11-30 Thread spmallette

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

https://github.com/apache/tinkerpop/pull/508#discussion_r90213680
  
--- Diff: docker/resources/groovy/grapeConfig.xml ---
@@ -1,15 +1,22 @@
 
   
+  
+  
+  
+
+  
   
 
+  
+
+
+  
   
 
 
   
-  http://repository.codehaus.org/; 
m2compatible="true"/>
-  http://central.maven.org/maven2/; 
m2compatible="true"/>
-  http://download.java.net/maven/2/; 
m2compatible="true"/>
-  http://obelix.ics.uci.edu/nexus/content/groups/hyracks-public-releases/; 
m2compatible="true"/>
--- End diff --

maybe you learned something new about grape, but why does this work without 
these entries? if giraph isn't in the local /.m2 or ./groovy then how will it 
get those dependencies?


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

48 matches

Mail list logo