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 <[email protected]>
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 <[email protected]>
> wrote:
>
> > yeah I like the barrier().store() best as well.
> >
> > On Wed, Sep 21, 2016 at 11:46 AM, Jean-Baptiste Musso <[email protected]
> > <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 <[email protected]
> > <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
>
