[GitHub] tinkerpop issue #343: restructured gremlin-python package

[davebshow]

Github user davebshow commented on the issue:

https://github.com/apache/tinkerpop/pull/343
  
This would probably be because the way tests are set up the modules are 
getting executed as a script instead of as a package. I don't know how to fix 
this off the top of my head--I haven't familiarized myself with how tests are 
being run, and I unfortunately don't have time to figure it out right now. 
Ideally, Gremlin-Python would be installed using pip and used normally as a 
package.


---
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 #343: restructured gremlin-python package

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/343
  
When I run the test suite, I get failures.

```
  File "src/main/jython/gremlin_python/groovy_translator.py", line 23, in 

from .gremlin_python import P
ValueError: Attempted relative import in non-package
```

Easy solution I can do or would you like to fix up your PR?


---
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: Planning for StarGraph's Serialization Format in TinkerPop 3.3.0

[Ted Wilmes]

If folks thought it was a good idea, I'd love to put together a little
benchmarking harness so that it would be easy to swap various
implementations & tweaks in and out to measure how they perform. For
example, benchmarks running against different #'s of vertex properties,
edge counts, # of properties / edge, measuring things like latency, size in
memory, and size on disk.  I need to finish up TinkerPop-1254, but then I
could take a crack at this.  I already have done some work towards this in
TinkerPop-1287 to confirm improvements from stream removal in key spots so
perhaps I could extend upon that.

--Ted

On Fri, Jun 17, 2016 at 3:49 PM, Marko Rodriguez 
wrote:

> Hi,
>
> TinkerPop 3.3.0 is not slated for anytime soon, but some buddies are
> interested in a making the serialization format of StarGraph more
> efficient. Given it would be a major breaking change, we can’t do it till
> TinkerPop 3.3.0, but we can talk about it and design it. Here is a ticket
> to get us underway. Your thoughts are more than welcome:
>
> https://issues.apache.org/jira/browse/TINKERPOP-1343 <
> https://issues.apache.org/jira/browse/TINKERPOP-1343>
>
> Take care,
> Marko.
>
> http://markorodriguez.com
>
>
>
>

[jira] [Updated] (TINKERPOP-1343) A more efficient StarGraph serialization representation.

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez updated TINKERPOP-1343:
--
Description: 
{{StarGraph}} is used by the Hadoop {{GraphComputers}} and represents a vertex, 
its properties, its incident edges, and their properties. In essence, one "row 
of an adjacency list."

Here are some ideas on how to make the next version of the serialization format 
more efficient.

1. For all Element ids, we currently use {{kryo.readClassAndObject(...)}}. This 
is bad because we have to write the class with each id. It would be better if 
the {{StarGraph}} had metadata like {{vertexIdClass}}, 
{{vertexPropertyIdClass}}, and {{edgeIdClass}}. Now for every vertex we are 
serializing three class, but the benefit is that every id class is now known 
and we can use {{kryo.readObject(..., xxxIdClass)}}.

2. Edges and VertexProperties are written out as {{[ edgeLabel[ edge[ id, 
otherVertexId]\*]\*}} and {{[ propertyKey[ vertexProperty[ 
id,propertyValue]\*]\*}}, respectively. This ensures we don't write so many 
strings as all edges/vertex properties are grouped by label. However, we do NOT 
do this for edge properties nor vertex property properties. We simply write out 
the {{Map>}} which is 
{{Map>}}. Since we have to choose between 
grouping by edgeId or by propertyKey, we should keep it as it is, but create a 
"meta map" that allows us to represent all property keys in a, e.g., {{int}} 
space. Thus, {{Map>}} where we 
also have a {{Map}} that is serialized with the 
{{StarGraph}}.

There are a few other tickets around optimizing {{StarGraph}} here:

https://issues.apache.org/jira/browse/TINKERPOP-1128 (making {{GraphFilters}} 
more efficient)

https://issues.apache.org/jira/browse/TINKERPOP-1122 (pointless bits and 
{{StarGraph}} should never auto-generate IDs as the ID space is distributed).

https://issues.apache.org/jira/browse/TINKERPOP-1287 (related to heap usage and 
clock cycles -- not serialization).


  was:
{{StarGraph}} is used by the Hadoop {{GraphComputers}} and represents a vertex, 
its properties, its incident edges, and their properties. In essence, one "row 
of an adjacency list."

Here are some ideas on how to make the next version of the serialization format 
more efficient.

1. For all Element ids, we currently use {{kryo.readClassAndObject(...)}}. This 
is bad because we have to write the class with each id. It would be better if 
the {{StarGraph}} had metadata like {{vertexIdClass}}, 
{{vertexPropertyIdClass}}, and {{edgeIdClass}}. Now for every vertex we are 
serializing three class, but the benefit is that every id class is now known 
and we can use {{kryo.readObject(..., xxxIdClass)}}.

2. Edges and VertexProperties are written out as 
{{[label[edge[id,otherVertexId]*]*}} and 
{{[label[vertexProperty[id,value]*]*}}, respectively. This ensures we don't 
write so many strings as all edges/vertex properties are grouped by label. 
However, we do NOT do this for edge properties nor vertex property properties. 
We simply write out the {{Map>}} which is 
{{Map>}}. Since we have to choose between 
grouping by edgeId or by propertyKey, we should keep it as it is, but create a 
"meta map" that allows us to represent all property keys in a, e.g., {{int}} 
space. Thus, {{Map>}} where we 
also have a {{Map}} that is serialized with the 
{{StarGraph}}.

There are a few other tickets around optimizing {{StarGraph}} here:

https://issues.apache.org/jira/browse/TINKERPOP-1128 (making {{GraphFilters}} 
more efficient)

https://issues.apache.org/jira/browse/TINKERPOP-1122 (pointless bits and 
{{StarGraph}} should never auto-generate IDs as the ID space is distributed).

https://issues.apache.org/jira/browse/TINKERPOP-1287 (related to heap usage and 
clock cycles -- not serialization).



> A more efficient StarGraph serialization representation.
> 
>
> Key: TINKERPOP-1343
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1343
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> {{StarGraph}} is used by the Hadoop {{GraphComputers}} and represents a 
> vertex, its properties, its incident edges, and their properties. In essence, 
> one "row of an adjacency list."
> Here are some ideas on how to make the next version of the serialization 
> format more efficient.
> 1. For all Element ids, we currently use {{kryo.readClassAndObject(...)}}. 
> 

[jira] [Created] (TINKERPOP-1343) A more efficient StarGraph serialization representation.

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1343:
-

 Summary: A more efficient StarGraph serialization representation.
 Key: TINKERPOP-1343
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1343
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.0-incubating
Reporter: Marko A. Rodriguez


{{StarGraph}} is used by the Hadoop {{GraphComputers}} and represents a vertex, 
its properties, its incident edges, and their properties. In essence, one "row 
of an adjacency list."

Here are some ideas on how to make the next version of the serialization format 
more efficient.

1. For all Element ids, we currently use {{kryo.readClassAndObject(...)}}. This 
is bad because we have to write the class with each id. It would be better if 
the {{StarGraph}} had metadata like {{vertexIdClass}}, 
{{vertexPropertyIdClass}}, and {{edgeIdClass}}. Now for every vertex we are 
serializing three class, but the benefit is that every id class is now known 
and we can use {{kryo.readObject(..., xxxIdClass)}}.

2. Edges and VertexProperties are written out as 
{{[label[edge[id,otherVertexId]*]*}} and 
{{[label[vertexProperty[id,value]*]*}}, respectively. This ensures we don't 
write so many strings as all edges/vertex properties are grouped by label. 
However, we do NOT do this for edge properties nor vertex property properties. 
We simply write out the {{Map>}} which is 
{{Map>}}. Since we have to choose between 
grouping by edgeId or by propertyKey, we should keep it as it is, but create a 
"meta map" that allows us to represent all property keys in a, e.g., {{int}} 
space. Thus, {{Map>}} where we 
also have a {{Map}} that is serialized with the 
{{StarGraph}}.

There are a few other tickets around optimizing {{StarGraph}} here:

https://issues.apache.org/jira/browse/TINKERPOP-1128 (making {{GraphFilters}} 
more efficient)

https://issues.apache.org/jira/browse/TINKERPOP-1122 (pointless bits and 
{{StarGraph}} should never auto-generate IDs as the ID space is distributed).

https://issues.apache.org/jira/browse/TINKERPOP-1287 (related to heap usage and 
clock cycles -- not serialization).




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

gremlin-variant python dependencies

[Leifur Halldor Asgeirsson]

The gremlin-variant tests currently fail unless the aenum package has been 
installed and added to PYTHONPATH. I notice that the mavenjython plugin can 
download and install python packages 
(http://mavenjython.sourceforge.net/compile/) but when I add aenum to the 
plugin configuration, it still doesn't seem to be available to the tests. This 
could be because I'm not using maven properly.


If that's not applicable to this use case, to run the tests on travis, we could 
create a virtualenv, install aenum, and add it to the PYTHONPATH. This could be 
done by a shell script, run by travis before 'mvn clean install'.

[jira] [Created] (TINKERPOP-1342) Allow setting scriptEvaluationTimeout in driver

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1342:
---

 Summary: Allow setting scriptEvaluationTimeout in driver
 Key: TINKERPOP-1342
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1342
 Project: TinkerPop
  Issue Type: Improvement
  Components: driver
Affects Versions: 3.1.2-incubating
Reporter: stephen mallette
Assignee: stephen mallette
 Fix For: 3.1.3


Allow this setting to be applied in the driver somehow so as to give the user 
the ability to override the server setting in the request.



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