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 aggregate at the barrier then store all at once
in 'x'
After strategies are applied there may not be any real difference.
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')?
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
