You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Moore, Branden James" <bj...@sandia.gov> on 2018/02/20 22:09:26 UTC
Re: [EXTERNAL] Re: gremlin-python lambdas, and
HaltedTraverserStrategy(DetachedFactory)
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" <sp...@gmail.com> 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 <sp...@gmail.com>
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 <bj...@sandia.gov>
> 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
>>
>>
>
Re: [EXTERNAL] Re: gremlin-python lambdas, and HaltedTraverserStrategy(DetachedFactory)
Posted by Robert Dale <ro...@gmail.com>.
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 <bj...@sandia.gov>
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" <ro...@gmail.com> wrote:
>
> You can return all properties with valueMap(true)
>
> Robert Dale
>
> On Wed, Feb 21, 2018 at 10:17 AM, Moore, Branden James <
> bjmoor@sandia.gov>
> 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" <sp...@gmail.com>
> 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 <
> > bjmoor@sandia.gov>
> > 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" <sp...@gmail.com>
> > 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 <
> > > spmallette@gmail.com>
> > > 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 <
> > > bjmoor@sandia.gov>
> > > > 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
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
Re: [EXTERNAL] Re: gremlin-python lambdas, and
HaltedTraverserStrategy(DetachedFactory)
Posted by "Moore, Branden James" <bj...@sandia.gov>.
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" <ro...@gmail.com> wrote:
You can return all properties with valueMap(true)
Robert Dale
On Wed, Feb 21, 2018 at 10:17 AM, Moore, Branden James <bj...@sandia.gov>
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" <sp...@gmail.com> 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 <
> bjmoor@sandia.gov>
> 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" <sp...@gmail.com>
> 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 <
> > spmallette@gmail.com>
> > 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 <
> > bjmoor@sandia.gov>
> > > 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
> > >>
> > >>
> > >
> >
> >
> >
>
>
>
Re: [EXTERNAL] Re: gremlin-python lambdas, and HaltedTraverserStrategy(DetachedFactory)
Posted by Robert Dale <ro...@gmail.com>.
You can return all properties with valueMap(true)
Robert Dale
On Wed, Feb 21, 2018 at 10:17 AM, Moore, Branden James <bj...@sandia.gov>
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" <sp...@gmail.com> 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 <
> bjmoor@sandia.gov>
> 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" <sp...@gmail.com>
> 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 <
> > spmallette@gmail.com>
> > 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 <
> > bjmoor@sandia.gov>
> > > 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
> > >>
> > >>
> > >
> >
> >
> >
>
>
>
Re: [EXTERNAL] Re: gremlin-python lambdas, and
HaltedTraverserStrategy(DetachedFactory)
Posted by "Moore, Branden James" <bj...@sandia.gov>.
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" <sp...@gmail.com> 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 <bj...@sandia.gov>
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" <sp...@gmail.com> 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 <
> spmallette@gmail.com>
> 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 <
> bjmoor@sandia.gov>
> > 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
> >>
> >>
> >
>
>
>
Re: [EXTERNAL] Re: gremlin-python lambdas, and HaltedTraverserStrategy(DetachedFactory)
Posted by Stephen Mallette <sp...@gmail.com>.
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 <bj...@sandia.gov>
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" <sp...@gmail.com> 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 <
> spmallette@gmail.com>
> 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 <
> bjmoor@sandia.gov>
> > 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
> >>
> >>
> >
>
>
>