[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408176#comment-16408176
]
Daniel Weber edited comment on TINKERPOP-1924 at 3/21/18 4:23 PM:
------------------------------------------------------------------
I don't have the specific need of such output. I am developing an ORM for
Gremlin in C# ([https://github.com/ExRam/ExRam.Gremlinq]) and stumbled upon
this inbalance of the Gremlin-API. The workaround using union is tested here
([https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Tests/GremlinQueryLanguageTest.cs#L1509)]
and is a bit ugly, so I wanted to point it out and possibly improve this.
was (Author: daniel.weber):
I don't have the specific need of such output. I am developing an ORM for
Gremlin in C# (https://github.com/ExRam/ExRam.Gremlinq) and stumbled upon this
inbalance of the Gremlin-API. The workaround for union is tested here
([https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Tests/GremlinQueryLanguageTest.cs#L1509)]
and is a bit ugly, so I wanted to point it out and possibly improve this.
> Make meta-properties accessible via values(...)-step
> ----------------------------------------------------
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
> Affects Versions: 3.3.1
> Reporter: Daniel Weber
> Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
