[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Weber updated TINKERPOP-1924:
------------------------------------
Description:
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 arbitraty
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.
was:
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 arbitraty
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.
> 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
> arbitraty 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)
