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