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().has('name','marko').valueMap(true).next()
==>label=person
==>name=[marko]
==>id=1
==>age=[29]
gremlin> g.V(map.get(T.id))
==>v[1]
Robert Dale
On Wed, Feb 21, 2018 at 11:32 AM, Moore, Branden James <[email protected]>
wrote:
> 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" <[email protected]> wrote:
>
> You can return all properties with valueMap(true)
>
> Robert Dale
>
> On Wed, Feb 21, 2018 at 10:17 AM, Moore, Branden James <
> [email protected]>
> 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 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 about specifying those properties to the API call.
> >
> > I certainly agree that always returning all properties is a waste of
> > bandwidth and processing, however, when building abstraction layers,
> it is
> > nice to avoid leaking design decisions of the underlying system.
> >
> > On 2/21/18, 4:49 AM, "Stephen Mallette" <[email protected]>
> wrote:
> >
> > 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
> > return the data that you need in the first place?
> >
> > On Tue, Feb 20, 2018 at 5:09 PM, Moore, Branden James <
> > [email protected]>
> > wrote:
> >
> > > 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 conversation about whether Gremlin would return properties
> has
> > reached
> > > the conclusion that it largely won't. However, TinkerPop
> still does
> > > support using DetachedFactory; though python-gremlin still
> does not
> > have
> > > the ability to deserialize those properties.
> > >
> > > I suppose if that is the strategy going forward (for
> gremlin-python
> > Vertex
> > > objects to not have Properties exposed in the API), there
> isn't much
> > point
> > > to me using the DetachedFactory; rather, I should come up with
> some
> > other
> > > work-around to enable grabbing properties programmatically.
> Perhaps
> > a lazy
> > > 'properties()' method that queries back to the server to get
> the
> > properties
> > > requested.
> > >
> > >
> > > On 2/20/18, 1:30 PM, "Stephen Mallette" <[email protected]>
> > wrote:
> > >
> > > thanks for adding this:
> > >
> > > https://issues.apache.org/jira/browse/TINKERPOP-1895
> > >
> > > i just commented. note that if you want to reduce
> extraneous
> > data, you
> > > don't want to use DetachedFactory. You want
> ReferenceFactory.
> > But, for
> > > 3.3.1, we already configure the server with
> > HaltedTraverserStrategy
> > > using
> > > ReferenceFactory - see my code example in the comments on
> that
> > issue.
> > >
> > > On Tue, Feb 20, 2018 at 2:39 PM, Stephen Mallette <
> > > [email protected]>
> > > wrote:
> > >
> > > > no, it's not. that's really strange. can you please
> create an
> > issue
> > > in
> > > > jira for that?
> > > >
> > > > On Tue, Feb 20, 2018 at 2:15 PM, Moore, Branden James <
> > > [email protected]>
> > > > wrote:
> > > >
> > > >> We’re using our gremlin-python traversals with the
> > > >> HaltedTraverserStrategy(o.a.t.g.s.u.d.DetachedFactory),
> to
> > > decrease the
> > > >> extraneous amount of data returned in large queries.
> Today I
> > > discovered
> > > >> that if one uses this strategy, lambdas no longer work.
> > > >>
> > > >> For example, from the TinkerPop docs:
> > > >> g.V().out().map(lambda: "lambda x:
> > len(x.get().value('name'))").s
> > > >> um().toList()
> > > >>
> > > >> Will give an error:
> > > >> GremlinServerError: 599: NameError: name
> 'TraversalStrategy'
> > is not
> > > >> defined in <script> at line number 1
> > > >>
> > > >> Is this the expected behavior when using the
> > > >> HaltedTraverserStrategy(DetachedFactory) ?
> > > >>
> > > >> Thanks,
> > > >>
> > > >> * Branden
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
