[
https://issues.apache.org/jira/browse/TINKERPOP-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15683838#comment-15683838
]
ASF GitHub Bot commented on TINKERPOP-1520:
-------------------------------------------
Github user okram commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/499#discussion_r88915459
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java
---
@@ -175,8 +177,30 @@ public PropertyJacksonSerializer() {
public void serialize(final Property property, final JsonGenerator
jsonGenerator, final SerializerProvider serializerProvider)
throws IOException {
jsonGenerator.writeStartObject();
- jsonGenerator.writeObjectField(GraphSONTokens.KEY,
property.key());
+ jsonGenerator.writeStringField(GraphSONTokens.KEY,
property.key());
jsonGenerator.writeObjectField(GraphSONTokens.VALUE,
property.value());
+ if (property.element() instanceof VertexProperty) {
+ VertexProperty vertexProperty = (VertexProperty)
property.element();
+
jsonGenerator.writeObjectFieldStart(GraphSONTokens.ELEMENT);
+ jsonGenerator.writeStringField(GraphSONTokens.VALUETYPE,
"g:VertexProperty");
+
jsonGenerator.writeObjectFieldStart(GraphSONTokens.VALUEPROP);
+ jsonGenerator.writeObjectField(GraphSONTokens.ID,
vertexProperty.id());
+ jsonGenerator.writeStringField(GraphSONTokens.LABEL,
vertexProperty.label());
+ jsonGenerator.writeObjectField(GraphSONTokens.VERTEX,
vertexProperty.element().id());
--- End diff --
Because a `VertexProperty` is attached to a `Vertex` and thus, generalized
`Element` semantics would only cause a chain of JSON unnecessary when `Vertex`
attachement only requires a single ID -- the vertex id.
> Difference between 'has' step generated graphson2.0 in java and python glv
> implementation
> -----------------------------------------------------------------------------------------
>
> Key: TINKERPOP-1520
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1520
> Project: TinkerPop
> Issue Type: Bug
> Components: language-variant
> Affects Versions: 3.2.3
> Reporter: Andy Tolbert
>
> Noticed that between the java and python implementations, the graphson2.0
> payload generated for a {{has}} step is different. i.e. for the given
> traversal:
> {{g.E().has("weight", 0.2)}}
> The java implementation produces the following graphson:
> {code:javascript}
> {"@type":"g:Bytecode","@value":{"step":[["E"],["has","weight",{"@type":"g:P","@value":{"predicate":"eq","value":{"@type":"g:Double","@value":0.2}}}]]}}
> {code}
> where the python implementation produces the following:
> {code:javascript}
> {"@type":"g:Bytecode","@value":{"step":[["E"],["has","weight",0.2]]}}
> {code}
> In the java case, a {{g\:P}} typed (predicate) value is provided, where in
> the python case that isn't the case.
> I'm assuming the java one is correct (primarily since the graph backend seems
> to like it and return the expected result). Should GLV implementations
> behave this way? I noticed that {{GraphTraversal#has(String propertyKey,
> Object value)}} in the java TinkerPop api wraps the value in a predicate
> ({{P.eq}}) under the covers
> ([link|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L922])
> so maybe implementors will need to do the same ([python
> link|https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/process/graph_traversal.py#L193])?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
