valueMap(true) contains all properties of a vertex including T.id which can
be passed to g.V(x)
gremlin> graph = TinkerFactory.createModern()
==>tinkergraph[vertices:6 edges:6]
gremlin> g = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> map = g.V().ha
Indeed, however, that returns a Map, not a Vertex which can be passed as a
starting point to future traversals.
Also, until 3.3.2 is released, 'valueMap(True)' doesn't work in python-gremlin.
(TINKERPOP-1860)
On 2/21/18, 9:21 AM, "Robert Dale" wrote:
You can return all properties with v
You can return all properties with valueMap(true)
Robert Dale
On Wed, Feb 21, 2018 at 10:17 AM, Moore, Branden James
wrote:
> If I'm building an API to interact with a Property Graph, and that API
> looks like:
> nodes = get_nodes_that_match_some_property()
>
> as an API, I cannot know what pro
If I'm building an API to interact with a Property Graph, and that API looks
like:
nodes = get_nodes_that_match_some_property()
as an API, I cannot know what properties might be needed later. As long as my
node type has some ability to fetch properties, then the user doesn't have to
worry abo
yes - for now, that is the direction. we want to encourage users to limit
results to just what they want to get. returning a vertex/edge and all its
properties isn't typically a good practice. do you really need to build a
lazy property feature? any reason to not just adjust your traversal to
retur
Thanks. I mis-remembered about the rationale for using DetachedFactory. In
reality, it was because we DID want the properties to be returned. Back in
2016, with TINKERPOP-1474, I had a PR in to add the ability to query properties
on python deserialized Vertex objects. It appears that the c
