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 > > >> > > >> > > > > > > > > > > > >
