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. > .barrier().store('x') would aggregate at the barrier then store all at once > in 'x' > After strategies are applied there may not be any real difference. Correct. > Although I'm a little confused by the local/global statement and how it > relates to lazy/eager collections. I definitely see .as() being 'local' > or per each entity whereas store() is a collection (not sure about scope). > So maybe the thought was that store(local) acts like as()? but then it > would have to take another parameter for the label or still use as() in > addition. .store(local, 'a'), or .store(local).as('a'), > .store(global).as('a'), .barrier().store(global).as('a’)? Scope.global and Scope.local are simply tokens that mean, in general: “for all traversers up to this step” — global “for the current traverser at this step” — local Thus, store(local) would “store the current traverser at this step.” store(global) would “store all traversers up to this step." Ah. I see your confusion now — yes, we would would still need a side-effect variable name: store(local, “x”) store(global, “x”) …and no, this is not as(“x”) as as(“x”) labels a step. Store requires the side-effect variable name. HTH, Marko. > > > On Wed, Sep 21, 2016 at 9:15 AM, Ted Wilmes <twil...@gmail.com> wrote: > >> 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().out().store('x').barrier().limit(1).cap('x') >> ==>[v[3],v[3],v[3],v[2],v[4],v[5]] >> >> With the barrier before the store in DFS, I would assume the store side >> effect would still be lazily populated. Having said that I know we could >> make it work that way just fine, it just reads a little unintuitively to >> me. Curious to see what you guys think of that though because I may have >> things turned around in my head. >> >> --Ted >> >> On Wed, Sep 21, 2016 at 4:59 AM, Jean-Baptiste Musso <jbmu...@gmail.com> >> wrote: >> >>> 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 < >> dylan.milli...@gmail.com> >>> wrote: >>> >>>> yeah I like the barrier().store() best as well. >>>> >>>> On Wed, Sep 21, 2016 at 11:46 AM, Jean-Baptiste Musso < >> jbmu...@gmail.com >>>> <javascript:;>> >>>> 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 .store()/.aggregate(). >>>>> >>>>> On Tuesday, 20 September 2016, Marko Rodriguez <okramma...@gmail.com >>>> <javascript:;>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I was thinking that store() and aggregate() should simply be >>> “store().” >>>>>> >>>>>> store() -> store(local) >>>>>> aggregate() -> store(global) >>>>>> >>>>>> Or: >>>>>> >>>>>> aggregate() -> barrier().store() >>>>>> >>>>>> Random thoughts… >>>>>> >>>>>> Marko. >>>>>> >>>>>> http://markorodriguez.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Jean-Baptiste >>>>> >>>> >>> >>> >>> -- >>> Jean-Baptiste >>> >> > > > > -- > Robert Dale