[
https://issues.apache.org/jira/browse/TINKERPOP-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15677284#comment-15677284
]
ASF GitHub Bot commented on TINKERPOP-1520:
-------------------------------------------
Github user spmallette commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/499#discussion_r88705921
--- Diff: CHANGELOG.asciidoc ---
@@ -26,6 +26,12 @@
image::https://raw.githubusercontent.com/apache/tinkerpop/master/docs/static/ima
TinkerPop 3.2.4 (Release Date: NOT OFFICIALLY RELEASED YET)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* Added "attachment requisite" `VertexProperty.element()` and
`Property.element()` data in GraphSON serialization.
+* Added `Vertex`, `Edge`, `VertexProperty`, and `Property` serializers to
Gremlin-Python and exposed tests that use graph object arguments.
+* `Bytecode.getSourceInstructions()` and `Bytecode.getStepInstructions()`
now returns `List<Instruction>` instead of `Iterable<Instruction>`.
+* Added various `TraversalStrategy` registrations with `GryoMapper`.
+* Fixed a naming mistake in Gremlin-Python: `IdentityRemoveStrategy` is
now called `IdentityRemovalStrategy`. (*breaking*)
--- End diff --
I've noticed that in the last few versions you've started adding "breaking"
to changelog entries. I've been tying "breaking" to tickets that will then show
up in the changelog on release. We can start doing this from now i guess, but
it's not been done consistently in changelog in any way. I guess that's a
really minor breaking change which wouldn't warrant a separate ticket. I dunno
- do we want to keep doing this and should it be done consistently going
forward?
> 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)
