Re: Store and Aggregate

2016-11-15 Thread Marko Rodriguez
Hi, I made a ticket for this: https://issues.apache.org/jira/browse/TINKERPOP-1553 Marko. http://markorodriguez.com > On Sep 26, 2016, at 9:35 AM, Marko Rodriguez wrote: > > Hello, > >> I imagine that .store('x').barrier() an

Re: Store and Aggregate

2016-09-26 Thread Marko Rodriguez
Hello, > I imagine that .store('x').barrier() and .barrier().store('x') would have > the same end result while taking slightly different paths at least with how > I read the definitions as they are today in OLTP. Yes, they would. > .store('x').barrier() would lazily fill 'x' up to the barrier. >

Re: Store and Aggregate

2016-09-21 Thread Robert Dale
I imagine that .store('x').barrier() and .barrier().store('x') would have the same end result while taking slightly different paths at least with how I read the definitions as they are today in OLTP. .store('x').barrier() would lazily fill 'x' up to the barrier. .barrier().store('x') would aggrega

Re: Store and Aggregate

2016-09-21 Thread Ted Wilmes
I like the idea of deprecating aggregate and combining barrier with store to get the same behavior, but the flipped version makes more sense to me "store().barrier()" when running in OLTP mode. gremlin> g.V().out().aggregate('x').limit(1).cap('x') ==>[v[3],v[3],v[3],v[2],v[4],v[5]] gremlin> g.V().

Re: Store and Aggregate

2016-09-21 Thread Jean-Baptiste Musso
I also recall Daniel mentioning in a post that .store() in OLAP works like .aggregate() in OLTP so this change could help users distinguish between both worlds and BFS/DFS. On Wednesday, 21 September 2016, Dylan Millikin wrote: > yeah I like the barrier().store() best as well. > > On Wed, Sep 21

Re: Store and Aggregate

2016-09-21 Thread Dylan Millikin
yeah I like the barrier().store() best as well. On Wed, Sep 21, 2016 at 11:46 AM, Jean-Baptiste Musso wrote: > I think barrier().store() for .aggregate() is very appropriate and fully > tells what is going on. > > I like both, +1 for one or the other. > > People also tend to confuse .as() and .s

Re: Store and Aggregate

2016-09-21 Thread Jean-Baptiste Musso
I think barrier().store() for .aggregate() is very appropriate and fully tells what is going on. I like both, +1 for one or the other. People also tend to confuse .as() and .store()/.aggregate(). On Tuesday, 20 September 2016, Marko Rodriguez wrote: > Hi, > > I was thinking that store() and ag

Re: Store and Aggregate

2016-09-20 Thread Dylan Millikin
+1 I find this to be way more explicit. Kinda got tripped by this a while back. On Tue, Sep 20, 2016 at 3:38 PM, Daniel Kuppitz wrote: > +1 > > On Tue, Sep 20, 2016 at 3:35 PM, Marko Rodriguez > wrote: > > > Hi, > > > > I was thinking that store() and aggregate() should simply be “store().” > >

Re: Store and Aggregate

2016-09-20 Thread Daniel Kuppitz
+1 On Tue, Sep 20, 2016 at 3:35 PM, Marko Rodriguez wrote: > Hi, > > I was thinking that store() and aggregate() should simply be “store().” > > store() -> store(local) > aggregate() -> store(global) > > Or: > > aggregate() -> barrier().store() > > Random tho