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

Reply via email to