[jira] [Commented] (TINKERPOP-1629) Allow reducing barriers in repeat()
[
https://issues.apache.org/jira/browse/TINKERPOP-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877348#comment-15877348
]
Daniel Kuppitz commented on TINKERPOP-1629:
---
Correct, {{lop}} and {{ripple}} are actually the expected values.
> Allow reducing barriers in repeat()
> ---
>
> Key: TINKERPOP-1629
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1629
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> The following query transforms the modern graph into layers:
> {noformat}
> gremlin>
> g.V(1).aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..1>
> aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..2>
> aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..3>cap("x").next()
> ==>[v[1]]
> ==>[v[3],v[2],v[4]]
> ==>[v[6],v[5]]
> {noformat}
> The index of each list represents the minimum distance of the vertices it
> contains from {{v\[1]}}.
> There's obviously a lot of code duplication, but even worse: the max. depth
> has to be known upfront. {{repeat()}} could solve that, but currently fails
> if it contains a reducing barrier step (in OLTP and OLAP).
> {noformat}
> gremlin>
> g.V(1).repeat(aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup()).cap("x").next()
> The parent of a reducing barrier can not be repeat()-step: FoldStep
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1362) nest steps in reference doc
[ https://issues.apache.org/jira/browse/TINKERPOP-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876717#comment-15876717 ] stephen mallette commented on TINKERPOP-1362: - I sorta like this idea, but not sure how we would do this with asciidoc. The menu on the left is controlled by headers in the asciidoc, so without adding all those steps as individual sections i don't see how this one can get done and I'm not sure we want to start going down that path as some of the grouped steps seem to make sense the way they are currently documented. wdyt [~pluradj] ? > nest steps in reference doc > --- > > Key: TINKERPOP-1362 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1362 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.2.0-incubating, 3.1.2-incubating >Reporter: Jason Plurad >Priority: Trivial > Labels: easyfix, newbie > > A colleague recommended that the reference doc should include links on the > left to some of the steps that are hidden underneath other steps. For example: > * Lambda Steps > ** Map > ** FlatMap > ** Filter > ** SideEffect > ** Branch > * Has Step > ** Has > ** HasLabel > ** HasId > ** HasKey > ** HasValue > ** HasNot -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1566) Kerberos authentication for gremlin-server
[
https://issues.apache.org/jira/browse/TINKERPOP-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876686#comment-15876686
]
ASF GitHub Bot commented on TINKERPOP-1566:
---
Github user vtslab commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/534#discussion_r102313638
--- Diff:
gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/handler/HttpBasicAuthenticationHandler.java
---
@@ -92,6 +102,13 @@ public void channelRead(final ChannelHandlerContext
ctx, final Object msg) {
try {
authenticator.authenticate(credentials);
ctx.fireChannelRead(request);
+
+// User name logged with the remote socket address and
authenticator classname for audit logging
+if (authenticationSettings.enableAuditLog) {
+String[] authClassParts =
authenticator.getClass().toString().split("[.]");
+auditLogger.info("User {} with address {}
authenticated by {}", credentials.get(PROPERTY_USERNAME),
+
ctx.channel().remoteAddress().toString().substring(1),
authClassParts[authClassParts.length - 1]);
--- End diff --
Thanks for clarifying, I will correct it. Tests are still running.
> Kerberos authentication for gremlin-server
> --
>
> Key: TINKERPOP-1566
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1566
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Reporter: Marc de Lignie
>Priority: Minor
> Labels: security
> Fix For: 3.3.0
>
>
> Gremlin server would benefit from an explicit Kerberos authentication plugin,
> because preparing and maintaining such a plugin is nontrivial. Also, many
> other Apache project provide kerberized services.
> In gremlin-console the standard Krb5LoginModule can be configured.
> Gremlin-server already includes the pluggable Sasl framework that can host
> the proposed Kerberos authentication plugin.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop pull request #534: TINKERPOP-1566 Kerberos authentication for grem...
Github user vtslab commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/534#discussion_r102313638
--- Diff:
gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/handler/HttpBasicAuthenticationHandler.java
---
@@ -92,6 +102,13 @@ public void channelRead(final ChannelHandlerContext
ctx, final Object msg) {
try {
authenticator.authenticate(credentials);
ctx.fireChannelRead(request);
+
+// User name logged with the remote socket address and
authenticator classname for audit logging
+if (authenticationSettings.enableAuditLog) {
+String[] authClassParts =
authenticator.getClass().toString().split("[.]");
+auditLogger.info("User {} with address {}
authenticated by {}", credentials.get(PROPERTY_USERNAME),
+
ctx.channel().remoteAddress().toString().substring(1),
authClassParts[authClassParts.length - 1]);
--- End diff --
Thanks for clarifying, I will correct it. Tests are still running.
---
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] [Assigned] (TINKERPOP-1614) Improve documentation for Graph.V() and Graph.E() on main docs page
[ https://issues.apache.org/jira/browse/TINKERPOP-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reassigned TINKERPOP-1614: --- Assignee: stephen mallette (was: Daniel Kuppitz) > Improve documentation for Graph.V() and Graph.E() on main docs page > --- > > Key: TINKERPOP-1614 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1614 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Reporter: Bob Briody >Assignee: stephen mallette > > I was trying to help someone out on stack overflow recently: > http://stackoverflow.com/questions/41638792/dse-graph-get-all-edges-between-two-vertexes. > I was on the main TinkerPop3 Docs page looking for some introduction to > g.V() that would be good to copy/paste, but couldn't find anything. > It seems like there might be a stepping stone missing between "The Traversal" > and "Graph Traversal Steps" - a stepping stone about using V and E to > seed/start a Traversal. > The use of IDs should also be discussed there as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1340) docs do not state at what version an API was introduced (or deprecated)
[
https://issues.apache.org/jira/browse/TINKERPOP-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1340:
[~pluradj] i've implemented a portion of what you described here, by adding
{{@since}} tags to the javadoc on {{GraphTraversal}}:
https://github.com/apache/tinkerpop/commit/c12e6ae517811d4d1634e2dbfa88c142021e68a2
https://github.com/apache/tinkerpop/commit/52040aa71b73843a0ccf6b757d762afe98df4db9
I don't think it works well in the reference documentation as there isn't
always a 1 to 1 mapping between the API and what's presented there. For
example, there might be an method that was introduced at 3.0.0-incubating but
got a fresh overload in 3.2.3 but is documented singularly in the reference
docs - not sure how we would reference those situations well. I would say there
is a similar issue with reference docs that group similar steps together.
Do you feel like that's enough to close this issue?
> docs do not state at what version an API was introduced (or deprecated)
> ---
>
> Key: TINKERPOP-1340
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1340
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Priority: Trivial
> Fix For: 3.2.5
>
>
> An all-to-common problem for new developers coming to the TinkerPop is
> figuring out which APIs work against the graph they are using. Since
> TinkerPop is ahead of many graph implementation out there (Titan/TP 3.0.1,
> Stardog/TP 3.0.2, Blazegraph/TP 3.1.0 -- kudos to Sqlg and Unipop for TP
> 3.2.0!), it's really important that developers know which APIs in the current
> docs are valid. Ideally the developers would go directly to that version of
> the TP docs, but that doesn't always happen thanks to Google.
> I propose doc updates on each Graph Traversal Step in the [reference
> docs|http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps]
> and in the javadocs (on
> [__.java|http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/__.html]
> and on specific step implementations, i.e.
> [AddEdgeStep.java|http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/step/map/AddEdgeStep.html]).
> It should state the specific version (3.y.z) the API was introduced or
> deprecated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1599) implement real gremlin-python driver
[
https://issues.apache.org/jira/browse/TINKERPOP-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876555#comment-15876555
]
ASF GitHub Bot commented on TINKERPOP-1599:
---
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/554
Well, I've made my last review of this code and pushed a bit of cleanup and
a small fix. IMHO, this is ready to be merged. I'll wait to see if there are
any more comments or feedback before upvoting.
> implement real gremlin-python driver
>
>
> Key: TINKERPOP-1599
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1599
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, language-variant
>Affects Versions: 3.2.3
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.3.0
>
>
> It is high time that gremlin-python comes packaged with a real driver. After
> watching the community discussion, it seems that the way to go will be to use
> the {{concurrent.futures}} module with multithreading to provide asynchronous
> I/O. While the default underlying websocket client library will remain
> Tornado due to Python 2/3 compatibility issues, this should be decoupled from
> the rest of the client and easy to replace.
> With this is mind, I created a baseline client implementation with [this
> commit|https://github.com/apache/tinkerpop/commit/fb7e7f255585956abbb854fcc5dd3138113cf454]
> in a topic branch {{python_driver}}. Some things to note:
> - All I/O is performed using the {{concurrent.futures}} module, which
> provides a standard 2/3 compatible future interface.
> - The implementation currently does not include the concept of a cluster,
> instead it assumes a single host.
> - The {{transport}} interface makes it easy to plug in client libraries by
> defining a simple wrapper.
> - Because this is an example, I didn't fix all the tests to work with the new
> client implementation. Instead I just added a few demo tests. If we decide to
> move forward with this I will update the original tests.
> The resulting API looks like this for a simple client:
> {code}
> client = Client('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal()
> t = g.V()
> future_result_set = client.submitAsync(t.bytecode)
> result_set = future_result_set.result()
> results = result_set.all().result()
> client.close()
> {code}
> Using the {{DriverRemoteConnection}}:
> {code}
> conn = DriverRemoteConnection('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal().withRemote(conn)
> t = g.V()
> results = t.toList()
> conn.close()
> {code}
> If you have a minute to check out the new driver code that would be great, I
> welcome feedback and suggestions. If we decide to move forward like this, I
> will proceed to finish the driver implementation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #554: TINKERPOP-1599 implement real gremlin-python driver
Github user davebshow commented on the issue: https://github.com/apache/tinkerpop/pull/554 Well, I've made my last review of this code and pushed a bit of cleanup and a small fix. IMHO, this is ready to be merged. I'll wait to see if there are any more comments or feedback before upvoting. --- 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-1599) implement real gremlin-python driver
[
https://issues.apache.org/jira/browse/TINKERPOP-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876387#comment-15876387
]
ASF GitHub Bot commented on TINKERPOP-1599:
---
Github user spmallette commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/554#discussion_r102272018
--- Diff: CHANGELOG.asciidoc ---
@@ -29,6 +29,11 @@ TinkerPop 3.2.5 (Release Date: NOT OFFICIALLY RELEASED
YET)
* Refactor `SparkContext` handler to support external kill and stop
operations.
* Fixed an optimization bug in `LazyBarrierStrategy` around appending
barriers to the end of a `Traversal`.
* `TraverserIterator` in GremlinServer is smart to try and bulk traversers
prior to network I/O.
+* Improved Gremlin-Python Driver implementation by adding a threaded
client with basic connection pooling and support for pluggable websocket
clients.
+
+Improvements
+
+TINKERPOP-1599 implement real gremlin-python driver
--- End diff --
you don't need to add those manually - they get added on release (we
generate a report out of jira for it).
> implement real gremlin-python driver
>
>
> Key: TINKERPOP-1599
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1599
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, language-variant
>Affects Versions: 3.2.3
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.3.0
>
>
> It is high time that gremlin-python comes packaged with a real driver. After
> watching the community discussion, it seems that the way to go will be to use
> the {{concurrent.futures}} module with multithreading to provide asynchronous
> I/O. While the default underlying websocket client library will remain
> Tornado due to Python 2/3 compatibility issues, this should be decoupled from
> the rest of the client and easy to replace.
> With this is mind, I created a baseline client implementation with [this
> commit|https://github.com/apache/tinkerpop/commit/fb7e7f255585956abbb854fcc5dd3138113cf454]
> in a topic branch {{python_driver}}. Some things to note:
> - All I/O is performed using the {{concurrent.futures}} module, which
> provides a standard 2/3 compatible future interface.
> - The implementation currently does not include the concept of a cluster,
> instead it assumes a single host.
> - The {{transport}} interface makes it easy to plug in client libraries by
> defining a simple wrapper.
> - Because this is an example, I didn't fix all the tests to work with the new
> client implementation. Instead I just added a few demo tests. If we decide to
> move forward with this I will update the original tests.
> The resulting API looks like this for a simple client:
> {code}
> client = Client('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal()
> t = g.V()
> future_result_set = client.submitAsync(t.bytecode)
> result_set = future_result_set.result()
> results = result_set.all().result()
> client.close()
> {code}
> Using the {{DriverRemoteConnection}}:
> {code}
> conn = DriverRemoteConnection('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal().withRemote(conn)
> t = g.V()
> results = t.toList()
> conn.close()
> {code}
> If you have a minute to check out the new driver code that would be great, I
> welcome feedback and suggestions. If we decide to move forward like this, I
> will proceed to finish the driver implementation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop pull request #554: TINKERPOP-1599 implement real gremlin-python dr...
Github user spmallette commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/554#discussion_r102272018 --- Diff: CHANGELOG.asciidoc --- @@ -29,6 +29,11 @@ TinkerPop 3.2.5 (Release Date: NOT OFFICIALLY RELEASED YET) * Refactor `SparkContext` handler to support external kill and stop operations. * Fixed an optimization bug in `LazyBarrierStrategy` around appending barriers to the end of a `Traversal`. * `TraverserIterator` in GremlinServer is smart to try and bulk traversers prior to network I/O. +* Improved Gremlin-Python Driver implementation by adding a threaded client with basic connection pooling and support for pluggable websocket clients. + +Improvements + +TINKERPOP-1599 implement real gremlin-python driver --- End diff -- you don't need to add those manually - they get added on release (we generate a report out of jira for it). --- 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-1629) Allow reducing barriers in repeat()
[
https://issues.apache.org/jira/browse/TINKERPOP-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876273#comment-15876273
]
Marko A. Rodriguez commented on TINKERPOP-1629:
---
The answer to the added {{RepeatTest}} traversal is:
{code}
gremlin> g.V(1).repeat(bothE().values("weight").sum().choose(is(gt(1)), V(6),
V(4)).out("created").dedup()).emit().values("name")
==>ripple
==>lop
{code}
It seems that {{josh}} and {{peter}} are expected. However, that seems wrong as
you want what they "created", NOT them themselves. Thus, I believe that the
test case written is bad.
> Allow reducing barriers in repeat()
> ---
>
> Key: TINKERPOP-1629
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1629
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> The following query transforms the modern graph into layers:
> {noformat}
> gremlin>
> g.V(1).aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..1>
> aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..2>
> aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..3>cap("x").next()
> ==>[v[1]]
> ==>[v[3],v[2],v[4]]
> ==>[v[6],v[5]]
> {noformat}
> The index of each list represents the minimum distance of the vertices it
> contains from {{v\[1]}}.
> There's obviously a lot of code duplication, but even worse: the max. depth
> has to be known upfront. {{repeat()}} could solve that, but currently fails
> if it contains a reducing barrier step (in OLTP and OLAP).
> {noformat}
> gremlin>
> g.V(1).repeat(aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup()).cap("x").next()
> The parent of a reducing barrier can not be repeat()-step: FoldStep
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1629) Allow reducing barriers in repeat()
[
https://issues.apache.org/jira/browse/TINKERPOP-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876267#comment-15876267
]
Marko A. Rodriguez commented on TINKERPOP-1629:
---
By allowing the internal `fold()`, the results for your example traversal are
as follows.
{code}
// OLTP
gremlin>
g.V(1).repeat(aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup()).cap("x").next()
==>[]
==>[v[1]]
==>[v[3],v[2],v[4]]
==>[v[6],v[5]]
// OLAP
gremlin>
g.withComputer().V(1).repeat(aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup()).cap("x").next()
==>[v[1]]
==>[]
==>[]
==>[]
==>[]
==>[]
==>[v[3],v[2],v[4]]
==>[v[5],v[6]]
gremlin>
{code}
> Allow reducing barriers in repeat()
> ---
>
> Key: TINKERPOP-1629
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1629
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> The following query transforms the modern graph into layers:
> {noformat}
> gremlin>
> g.V(1).aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..1>
> aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..2>
> aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup().
> ..3>cap("x").next()
> ==>[v[1]]
> ==>[v[3],v[2],v[4]]
> ==>[v[6],v[5]]
> {noformat}
> The index of each list represents the minimum distance of the vertices it
> contains from {{v\[1]}}.
> There's obviously a lot of code duplication, but even worse: the max. depth
> has to be known upfront. {{repeat()}} could solve that, but currently fails
> if it contains a reducing barrier step (in OLTP and OLAP).
> {noformat}
> gremlin>
> g.V(1).repeat(aggregate("a").fold().store("x").unfold().both().where(without("a")).dedup()).cap("x").next()
> The parent of a reducing barrier can not be repeat()-step: FoldStep
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1635) gremlin-python: Duplicate serialization of element property in PropertySerializer
[
https://issues.apache.org/jira/browse/TINKERPOP-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876262#comment-15876262
]
ASF GitHub Bot commented on TINKERPOP-1635:
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/561
Sure, I just noticed it while working on GraphSON for Gremlin.CSharp and it
seemed strange that integer properties were serialized twice.
> gremlin-python: Duplicate serialization of element property in
> PropertySerializer
> -
>
> Key: TINKERPOP-1635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1635
> Project: TinkerPop
> Issue Type: Bug
> Components: language-variant
>Affects Versions: 3.3.0
>Reporter: Florian Hockmann
>Priority: Trivial
>
> The {{PropertySerializer}} in the current master branch of gremlin-python
> serializes the element property twice:
> {code}
> elementDict = writer.toDict(property.element)
> #...
> "element": writer.toDict(elementDict)
> {code}
> This isn't a problem when the element only contains simple types like strings
> that aren't serialized by adding a type attribute (like in the unit test for
> this component). However, all other types like integers for example are
> serialized two times. So an integer will be serialized to:
> {code}
> {"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}}
> {code}
> Full example:
> {code}
> >>> p = Property("aKey","aValue", Edge(123, Vertex(1), "edgeLabel",
> >>> Vertex(2)))
> >>> writer.writeObject(p)
> '{"@type":"g:Property","@value":{"value":"aValue","key":"aKey","element":{"@type":"g:Edge","@value":{"inV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":2}},"id":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":123}},"outV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}},"label":"edgeLabel"'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1635) gremlin-python: Duplicate serialization of element property in PropertySerializer
[
https://issues.apache.org/jira/browse/TINKERPOP-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876256#comment-15876256
]
ASF GitHub Bot commented on TINKERPOP-1635:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/561
Note that we will be heavily refactoring GraphSON for TinkerPop 3.3.0
(`master/`) so most of this will be gutted. I will leave it up to @spmallette /
@newkek / @aholmberg to decide whether this is necessary to merge.
> gremlin-python: Duplicate serialization of element property in
> PropertySerializer
> -
>
> Key: TINKERPOP-1635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1635
> Project: TinkerPop
> Issue Type: Bug
> Components: language-variant
>Affects Versions: 3.3.0
>Reporter: Florian Hockmann
>Priority: Trivial
>
> The {{PropertySerializer}} in the current master branch of gremlin-python
> serializes the element property twice:
> {code}
> elementDict = writer.toDict(property.element)
> #...
> "element": writer.toDict(elementDict)
> {code}
> This isn't a problem when the element only contains simple types like strings
> that aren't serialized by adding a type attribute (like in the unit test for
> this component). However, all other types like integers for example are
> serialized two times. So an integer will be serialized to:
> {code}
> {"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}}
> {code}
> Full example:
> {code}
> >>> p = Property("aKey","aValue", Edge(123, Vertex(1), "edgeLabel",
> >>> Vertex(2)))
> >>> writer.writeObject(p)
> '{"@type":"g:Property","@value":{"value":"aValue","key":"aKey","element":{"@type":"g:Edge","@value":{"inV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":2}},"id":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":123}},"outV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}},"label":"edgeLabel"'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #561: TINKERPOP-1635 Fix duplicate serialization of element ...
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/561 Note that we will be heavily refactoring GraphSON for TinkerPop 3.3.0 (`master/`) so most of this will be gutted. I will leave it up to @spmallette / @newkek / @aholmberg to decide whether this is necessary to merge. --- 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-1635) gremlin-python: Duplicate serialization of element property in PropertySerializer
[
https://issues.apache.org/jira/browse/TINKERPOP-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876243#comment-15876243
]
ASF GitHub Bot commented on TINKERPOP-1635:
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/561
The PropertySerializer doesn't exist in the `tp32` branch, it was only
added to the master. So the problem also only exists in `master`.
> gremlin-python: Duplicate serialization of element property in
> PropertySerializer
> -
>
> Key: TINKERPOP-1635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1635
> Project: TinkerPop
> Issue Type: Bug
> Components: language-variant
>Affects Versions: 3.3.0
>Reporter: Florian Hockmann
>Priority: Trivial
>
> The {{PropertySerializer}} in the current master branch of gremlin-python
> serializes the element property twice:
> {code}
> elementDict = writer.toDict(property.element)
> #...
> "element": writer.toDict(elementDict)
> {code}
> This isn't a problem when the element only contains simple types like strings
> that aren't serialized by adding a type attribute (like in the unit test for
> this component). However, all other types like integers for example are
> serialized two times. So an integer will be serialized to:
> {code}
> {"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}}
> {code}
> Full example:
> {code}
> >>> p = Property("aKey","aValue", Edge(123, Vertex(1), "edgeLabel",
> >>> Vertex(2)))
> >>> writer.writeObject(p)
> '{"@type":"g:Property","@value":{"value":"aValue","key":"aKey","element":{"@type":"g:Edge","@value":{"inV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":2}},"id":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":123}},"outV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}},"label":"edgeLabel"'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #561: TINKERPOP-1635 Fix duplicate serialization of element ...
Github user FlorianHockmann commented on the issue: https://github.com/apache/tinkerpop/pull/561 The PropertySerializer doesn't exist in the `tp32` branch, it was only added to the master. So the problem also only exists in `master`. --- 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-1635) gremlin-python: Duplicate serialization of element property in PropertySerializer
[
https://issues.apache.org/jira/browse/TINKERPOP-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876231#comment-15876231
]
ASF GitHub Bot commented on TINKERPOP-1635:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/561
Should this be directed to `tp32/` and not `master/`? Or is this a breaking
change?
> gremlin-python: Duplicate serialization of element property in
> PropertySerializer
> -
>
> Key: TINKERPOP-1635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1635
> Project: TinkerPop
> Issue Type: Bug
> Components: language-variant
>Affects Versions: 3.3.0
>Reporter: Florian Hockmann
>Priority: Trivial
>
> The {{PropertySerializer}} in the current master branch of gremlin-python
> serializes the element property twice:
> {code}
> elementDict = writer.toDict(property.element)
> #...
> "element": writer.toDict(elementDict)
> {code}
> This isn't a problem when the element only contains simple types like strings
> that aren't serialized by adding a type attribute (like in the unit test for
> this component). However, all other types like integers for example are
> serialized two times. So an integer will be serialized to:
> {code}
> {"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}}
> {code}
> Full example:
> {code}
> >>> p = Property("aKey","aValue", Edge(123, Vertex(1), "edgeLabel",
> >>> Vertex(2)))
> >>> writer.writeObject(p)
> '{"@type":"g:Property","@value":{"value":"aValue","key":"aKey","element":{"@type":"g:Edge","@value":{"inV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":2}},"id":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":123}},"outV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}},"label":"edgeLabel"'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #561: TINKERPOP-1635 Fix duplicate serialization of element ...
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/561 Should this be directed to `tp32/` and not `master/`? Or is this a breaking change? --- 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. ---
