[
https://issues.apache.org/jira/browse/TINKERPOP-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695551#comment-15695551
]
ASF GitHub Bot commented on TINKERPOP-1483:
-------------------------------------------
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/446
This is interesting. I was unaware of some or didn't understand some
implementation details. Taking a step back and looking at this again, I wonder
if the original intent is more correct. Sorry @JPMoresmau
:smiley:
We have to ask what is the purpose of `Hidden`? And what is the purpose of
`T.*.getAccessor()`? Looks like `Has` step internally use `T.*.getAccessor()`
for equality tests. Is this more of an internal method or should it be exposed?
Ultimately, the question is with what or how do we expect to access `T`
tokens in a value map?
Given: `map = g.V().valueMap(true).next()`
Access by: `map.get(T.id)` **or** `map.get(T.id.getAccessor())`?
If the answer is `T.id` then the interface must be <Object,Object>
If the answer is `T.id.getAccessor()` then the interface must be
<String,Object>
In either case, there is no conflict between system-level `T` tokens (e.g.
`T.id`), as these are either Enum or `Hidden`, and user-level strings (e.g.
`id`).
> PropertyMapStep returns Map<String,E> but puts non String keys in it!
> ---------------------------------------------------------------------
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.2.2
> Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map<String,E>, but if includeTokens is
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in
> Java fails. toString() are missing... But do we rely on having these keys in
> other operations?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)