[
https://issues.apache.org/jira/browse/TINKERPOP-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-3309:
----------------------------------------
Issue Type: Bug (was: Improvement)
> Absent parameter key is treated as a null value for TinkerGQL
> -------------------------------------------------------------
>
> Key: TINKERPOP-3309
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3309
> Project: TinkerPop
> Issue Type: Bug
> Components: gql
> Affects Versions: 4.0.0
> Reporter: Stephen Mallette
> Priority: Minor
>
> The "Parameterized Queries" table in
> docs/src/reference/the-traversal.asciidoc lists two distinct behaviors for
> match(String, Map): a parameter key present with a null value "passes only
> for elements where the property is absent", while a key absent from the map
> "always fails — no element matches". In practice the two cases behave
> identically — an absent key passes for elements where the property is absent,
> and only matches nothing when every candidate happens to have the property.
>
> PropertyPredicate.test resolves the parameter with params.get(name), which
> returns null for an absent key just as it does for a key explicitly mapped to
> null, so there is no "always fails" path. DefaultGqlExecutor.seedIterator
> resolves seed-vertex parameters the same way. Observed on master at d45c55bf
> and still present at 85c4269d.
>
> Either the table row is wrong, or the implementation is. An absent key is
> usually a caller mistake such as a misspelled parameter name, and treating it
> as null silently widens the result set instead of failing loudly;
> params.containsKey(name) would distinguish the two cases. A documentation fix
> is ready, but it shouldn't land until the intended semantics are decided.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
