TINKERPOP-3247 Convert request bindings to gremlin-lang string format#3402
TINKERPOP-3247 Convert request bindings to gremlin-lang string format#3402
Conversation
316e283 to
8bed359
Compare
The visitor treated all keyword map keys as their text representation, so a null key in [null:"value"] was parsed as the String "null" instead of Java null. This broke round-tripping maps with null keys through GremlinLang serialization and ANTLR parsing.
Moving parameters from binary-serialized maps to string representations makes the request side pure text, decoupling Gremlin language evolution from GraphBinary versioning. New types can be introduced in minor/patch versions without touching GraphBinary, eliminating the need for a major version bump across the ecosystem for every new request-side type. The asParameter() fallback is replaced with an unsupportedType flag that records the class name and falls back to toString(). A flag is used rather than throwing because embedded Traversals build GremlinLang as a side effect but never send it, so unknown types must not break execution. All other GLVs throw immediately since they have no embedded mode and the early throw gives better errors. Client APIs accept both map and string bindings (but not both at the same time) because users who use the Client directly with raw Gremlin strings shouldn't need to hand-craft gremlin-lang map literals. Mixing both throws immediately to prevent silent loss where one set of bindings would be discarded. Edge and VertexProperty tests that relied on the old asParameter fallback were removed because they aren't supported in gremlin-lang.
| final GremlinParser.GenericMapLiteralContext mapCtx = parser.genericMapLiteral(); | ||
|
|
||
| final ParameterMapVisitor visitor = new ParameterMapVisitor(new GremlinAntlrToJava()); | ||
| final Map<Object, Object> rawMap = (Map<Object, Object>) visitor.visitGenericMapLiteral(mapCtx); |
There was a problem hiding this comment.
Do we need some error handling here? Am I right in assuming mapCtx will be null if the parameterMapString is not actually a gremlin-lang map? How would such an error propagate if the user provides a bad parameter string?
There was a problem hiding this comment.
Error handling is done via the GremlinErrorListener that throws a GremlinParserException if its not a map so there won't be a null. See the shouldReturnUserFriendlyErrorMessageForMalformedParameterStrings test for more info.
| if (value instanceof Traversal) { | ||
| throw new GremlinParserException("Traversals are not allowed as parameter values"); | ||
| } | ||
| if (value instanceof Map) { |
There was a problem hiding this comment.
Should we also recurse through map keys?
There was a problem hiding this comment.
This is just extra checking so neither technically needs to be exist, but yes, I'll add it for completeness.
| throw new GremlinParserException("Parameter map nesting depth exceeds maximum of " + maxNestingDepth); | ||
| } | ||
| try { | ||
| return super.visitGenericCollectionLiteral(ctx); |
There was a problem hiding this comment.
Am I right in understanding that this will result in all objects contained in the collection to be parsed by GenericLiteralVisitor.visitGenericLiteral() instead of ParameterMapVisitor.visitGenericLiteral()? Do we need more careful handling of collections and any composite types to ensure that they are recursively parsed through this class and not handed off to the unguarded GenericLiteralVisitor?
There was a problem hiding this comment.
Yes, thanks for pointing this out, something is definitely not right here. I modified the test in ParameterMapVisitorTest slightly to assert the exception message and it confirms that it isn't dispatching to the right visitor. I'll have to think about how to make a simple change to fix this.
|
|
||
| @Test(expected = GremlinParserException.class) | ||
| public void shouldRejectTerminatedTraversalInValue() { | ||
| GremlinQueryParser.parseParameters("[\"x\":g.V().drop().iterate()]"); |
There was a problem hiding this comment.
I think it might be worth a few more cases which try to bury a terminatedTraversal deeper inside other collections/composite types.
| return this; | ||
| } | ||
|
|
||
| addBindingsString(bindingsString: string): Builder { |
There was a problem hiding this comment.
Nit: addBindings acts as a merge, but addBindingsString is a replacement. I think that's ok to an extent, (we definitely don't want to try merging strings), but might be worth a quick jsdoc. Perhaps it would be also reasonable to only allow addBindingsString to be called once.
There was a problem hiding this comment.
Yea I think that should get commented so I'll update that. Regarding allowing it to only be called once, my opinion is that its not necessary for now. The documentation will say "last one wins".
https://issues.apache.org/jira/browse/TINKERPOP-3247
Moving parameters from binary-serialized maps to string representations
makes the request side pure text, decoupling Gremlin language evolution
from GraphBinary versioning. New types can be introduced in minor/patch
versions without touching GraphBinary, eliminating the need for a major
version bump across the ecosystem for every new request-side type.
The asParameter() fallback is replaced with an unsupportedType flag that
records the class name and falls back to toString(). A flag is used
rather than throwing because embedded Traversals build GremlinLang as a
side effect but never send it, so unknown types must not break
execution. All other GLVs throw immediately since they have no embedded
mode and the early throw gives better errors.
Client APIs accept both map and string bindings (but not both at the
same time) because users who use the Client directly with raw Gremlin
strings shouldn't need to hand-craft gremlin-lang map literals. Mixing
both throws immediately to prevent silent loss where one set of bindings
would be discarded.
Edge and VertexProperty tests that relied on the old asParameter
fallback were removed because they aren't supported in gremlin-lang.