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 <[email protected]> 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 <[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
>>>
>>
>
>
>
> --
> Robert Dale
