[
https://issues.apache.org/jira/browse/TINKERPOP-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698490#comment-17698490
]
ASF GitHub Bot commented on TINKERPOP-2824:
-------------------------------------------
spmallette commented on code in PR #1843:
URL: https://github.com/apache/tinkerpop/pull/1843#discussion_r1131292023
##########
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/binary/types/VertexPropertySerializer.java:
##########
@@ -66,7 +66,10 @@ protected void writeValue(final VertexProperty value, final
Buffer buffer, final
// we don't serialize the parent vertex, let's hold a place for it
context.write(null, buffer);
- final List<?> asList = IteratorUtils.toList(value.properties());
- context.write(asList, buffer);
+ // Neo4jVertexProperty throw UnsupportedOperationException for
properties,
+ // so for now VertexProperty will be serialized without inner
properties
+ // final List<?> asList = IteratorUtils.toList(value.properties());
+ // context.write(asList, buffer);
+ context.write(null, buffer);
Review Comment:
I'm not sure i understand the nature of the risk you're describing, but the
`keys()` implementation for `Neo4jGraph` is strange anyway. It returns an empty
`Set` while `properties()` throws an exception...that's pretty inconsistent.
I"m not even sure `vertexPropertyNode` is relevant - i have a feeling it is
dead code and `keys()` was missed in some refactoring at some point.
Neo4j really isn't the issue though. The real issue is how it works for any
`Graph` implementation that doesn't support metaproperties. As the current
approach has worked for years in GraphSON/Gryo I feel like we can fairly assume
it should be safe for GraphBinary.
That said, perhaps we should do better than assume. You could encode the
idea that `properties()` / `keys()` should not throw exceptions but instead
return empty iterables. You'd do that by modifying test semantics for
`FeatureSupportTest` and probably `VertexPropertyTest` (there might be others
that fail as a result of this change). This change would require Upgrade Docs
for providers to take note of. I think you'd want to wholly remove
`VertexProperty.Exception.metaPropertiesNotSupported` basically and see what
breaks.
> Properties on Elements
> ----------------------
>
> Key: TINKERPOP-2824
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2824
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet, driver, go, javascript, process, python
> Affects Versions: 3.5.4
> Reporter: Valentyn Kahamlyk
> Assignee: Valentyn Kahamlyk
> Priority: Major
> Labels: breaking
>
> Problem: When a user writes `g.V()` they get back a Vertex object. The
> problem is that depending on the execution context of the traversal, the
> result could be quite different, with or without properties.
> Solution: Implement new finalization strategy DetachStrategy(detachMode,
> properties) where mode is one of ALL, NONE or CUSTOM. `properties` is list of
> properties name, are taken into account only for CUSTOM mode.
> Discussion thread in dev list: [Proposal to handle properties on response
> Elements-Apache Mail
> Archives|https://lists.apache.org/thread/l8rw7ydj7kym8vhtwk50nhbp45ng9986]
> Stephen's thread in dev list: [The Issue of Detachment-Apache Mail
> Archives|https://lists.apache.org/thread/xltcon4zxnwq4fyw2r2126syyrqm8spy]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
