Hi,
I made a ticket for this:
https://issues.apache.org/jira/browse/TINKERPOP-1553
<https://issues.apache.org/jira/browse/TINKERPOP-1553>
Marko.
http://markorodriguez.com
> On Sep 26, 2016, at 9:35 AM, Marko Rodriguez <[email protected]> wrote:
>
> 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
>
