[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842565#comment-16842565
 ] 

Daniel Kuppitz commented on TINKERPOP-2220:
---

Just had another idea on how to explain it. Instead of {{dedup()}} let's just 
use a filter lambda that follows the same rules (and prints some debug 
messages):

{code}
gremlin> dedupLambda = {
..1>   element = it.get()
..2>   step = it.getStepId()
..3>   if ((m = (step =~ /[0-9]+\.[0-9]+\.[0-9]+\(\)/)).find()) {
..4> step = m.group()
..5>   }
..6>   seen = memory[step]?.contains(element)
..7>   memory[step] = (memory[step] ?: []) + [element]
..8>   println "${element} seen at step ${step}: ${seen ? 'yes (filter it)' 
: 'no (let it pass)'}"
..9>   return !seen
.10> }
==>groovysh_evaluate$_run_closure1@67514bdd
gremlin> 
gremlin> memory = [:] ; g.V().filter(dedupLambda).filter(dedupLambda).count()
v[1] seen at step 1.0.0(): no (let it pass)
v[1] seen at step 2.0.0(): no (let it pass)
v[2] seen at step 1.0.0(): no (let it pass)
v[2] seen at step 2.0.0(): no (let it pass)
v[3] seen at step 1.0.0(): no (let it pass)
v[3] seen at step 2.0.0(): no (let it pass)
v[4] seen at step 1.0.0(): no (let it pass)
v[4] seen at step 2.0.0(): no (let it pass)
v[5] seen at step 1.0.0(): no (let it pass)
v[5] seen at step 2.0.0(): no (let it pass)
v[6] seen at step 1.0.0(): no (let it pass)
v[6] seen at step 2.0.0(): no (let it pass)
==>6
gremlin> memory = [:] ; g.V().repeat(filter(dedupLambda)).times(2).count()
v[1] seen at step 1.0.0(): no (let it pass)
v[1] seen at step 1.0.0(): yes (filter it)
v[2] seen at step 1.0.0(): no (let it pass)
v[2] seen at step 1.0.0(): yes (filter it)
v[3] seen at step 1.0.0(): no (let it pass)
v[3] seen at step 1.0.0(): yes (filter it)
v[4] seen at step 1.0.0(): no (let it pass)
v[4] seen at step 1.0.0(): yes (filter it)
v[5] seen at step 1.0.0(): no (let it pass)
v[5] seen at step 1.0.0(): yes (filter it)
v[6] seen at step 1.0.0(): no (let it pass)
v[6] seen at step 1.0.0(): yes (filter it)
==>0
{code}

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842470#comment-16842470
 ] 

Daniel Kuppitz commented on TINKERPOP-2220:
---

{{dedup()}} is a {{FilterStep}}. Think about it, {{repeat(whatever).times(2)}} 
is supposed to emit whatever is left after the 2nd iteration. For 
{{repeat(dedup()).times(2)}} there's just nothing left in the stream as every 
element gets filtered in the 2nd iteration.

{code}
gremlin> g.V().repeat(dedup()).times(2).count()
==>0
gremlin> g.V().repeat(dedup()).emit().times(2).count()
==>6
{code}

If you emit all elements after each iteration, you'll get all the survivors 
from iteration 1. Does it make any more sense now?

It's not the same as {{dedup().dedup()}} as this only ensures uniqueness at two 
different steps in the traversal. And because it's not the same, 
{{RepeatUnrollStrategy}} won't do anything if it finds a {{DedupStep}}.

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Choi (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842430#comment-16842430
 ] 

Daniel Choi commented on TINKERPOP-2220:


Thanks Daniel, I see what you're getting at.  Although I feel like if dedup()'s 
meaning is different in the context of repeat, maybe it would've been better to 
separate it out as an explicit argument to do sort of "distinct" graph search 
(only process each node once).  repeat().distinct(true) or something like that. 
 It just seems weird that repeat() is normally meant to repeat the inner 
traversal verbatim, except if it's a dedup() then it's not (evidenced by 
special case handling of dedup() inside repeat() in unroll strategy). 

I realize repeat() is usually used to implement graph search like BFS in 
gremlin and there are strong merits to having a mechanism to reduce the 
frontier based on a visited set, and that dedup() is being used for this use 
case.  But it seems to start to muddy the semantics of repeat() and maybe it's 
better to have repeat() as verbatim repetition of the inner traversal while 
making separate dedicated steps for graph search (with various search related 
options: bfs, dfs, bi-directional, etc.)?

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: The Bytecode Pattern-Matching Model

[Marko Rodriguez]

Hi,

Kuppitz makes fun of me for my constant use of the word “tuple” for anything 
that has to do with TP4 structure/.

Perhaps this is the API:
https://gist.github.com/okram/84912722a2c00f26f07f1c4825eacd50 

My response below to Stephen is still worth reading as its more detailed and I 
assume you understand it for the link above.

What I like about the updated API:

Are you only talking RDBMS? 
TMap. “relations"
Are you only talking GraphDB? 
TMap, TPrimitive. “vertices” and “edges” and their property 
values.
@Josh: want to build a type system over graphdb —> 
“vertex+edge” = “relations”.
Are you only talking DocumentDB? 
TMap, TList, TPrimitive. “objects” containing “objects”, 
“lists”, “primitives"
Are you only talking Wide-Column? 
TMap. “relations"
…

I’ll stop for now. I don’t want to overload y’all. And its the freakin’ 
weekend… oh wait, everyday is the weekend for me.

Peace in the Far East (LA),
Marko.

http://rredux.com 




> On May 17, 2019, at 7:58 AM, Marko Rodriguez  wrote:
> 
> Hi,
> 
> Thanks for your question. 
> 
> I suppose that a “limit bandwidth”-optimization could be based on the 
> provider looking at all the instructions in the submitted instruction and 
> then use that information to constrain what bytecode patterns it exposes. A 
> simple ProviderStrategy would be the means of doing that.
> 
> Perhaps showing you what I think the Tuple API should look like would help. 
> This API would represent the primary way in which the TP VM interacts with 
> the structure/ provider. Thus, this is for all cookies in the cookie jar!
> 
> 
> 
> public interface Tuple extends Iterator> {
> 
>   public boolean hasKey(Object key);
>   public boolean hasValue(Object value);
>   public  Tuple get(Object key);
>   public A value();
>   public long count();
>   public boolean hasNext();
>   public Tuple next();
> 
>   public boolean match(Instruction instruction);
>   public Tuple apply(Instruction instruction);
>   
> }
> 
> 
> 
> Structure neo4j = Neo4jStructureFactory.open(config1)
> Tuple db = neo4j.root(); 
>   => { type:graph | [V] }#1
> 
> //
> 
> Let a = 
> 
> { type:vertex, name:marko, age:29 | [inE] [outE] }#1
> 
> a.count()   => 1
> a.value()   => 
> Map.of('type','vertex','name','marko','age',29)
> a.get('type')   => { 'vertex' }#1
> a.get('name')   => { 'marko' }#1
> a.hasKey('blah')=> false
> a.match(Instruction.of('outE')) => true
> 
> //
> 
> b = a.apply(Instruction.of('outE’))
> 
> { type:edge, label:?string | [outV] [inV] }#?
> 
> b.count()  => -1
> b.hasKey('weight') => null// not false because all we 
> know is type:edge & label:?string about #? of things.
> b.hasKey('type')   => true
> b.hasKey('label')  => true
> b.get('label') => { ?string }#?   // ?string is something 
> like Unknown.of(Type.string())
> 
> //
> 
> c = b.apply(Instruction.of('inV'))
> 
> { type:vertex }#?
> 
> c.count()  => -1
> c.value()  => Map.of('type','vertex')
> c.hasNext()=> true
> c.next()   => { type:vertex, name:stephen, age:17 | [inE] [outE] }
> c.hasNext()=> true
> c.next()   => { type:vertex, name:kuppitz | [inE] [outE] }
> c.hasNext()=> false
> c.count()  => 0
> 
> //
> 
> d = { type:vertex, name:kuppitz | [inE] [outE] }
> 
> e = d.get('name')
> 
> { kuppitz }#1
> 
> e.count() => 1
> e.value() => 'kuppitz'
> 
> //
> 
> Let f = 
> 
> { type:edge | [outV] [inV] [has,label,eq,?0] }?10
> 
> f.count()=> 10
> f.get('type')=> { 'edge' }#10
> f.match(Instruction.of('has','label',P.eq,'knows'))  => true
> 
> //
> 
> g = f.apply(Instruction.of('has','label',P.eq,'knows'))
> 
> { type:edge, label:knows | [outV] [inV] }#1
> 
> g.count()  => 1
> g.hasNext()=> true
> g.next()   => { type:edge, label:knows | [outV] [inV] }#1  // its 
> iteration is itself!
> g.hasNext()=> false// g lost the 
> reference
> g.count()  => 0
> 
> //
> 
> Cool? Questions?
> 
> Thanks,
> Marko.
> 
> http://rredux.com 
> 
> 
> 
> 
>> On May 17, 2019, at 6:57 AM, Stephen Mallette > > wrote:
>> 
>> This is a nicely refined representation of this concept. I think I've
>> followed this abstractly since you first started discussing it, but I've
>> struggled with the implementation of it and how it would best work (which
>> is probably the reason I keep thinking that I"m not foll

[jira] [Closed] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kuppitz closed TINKERPOP-2220.
-
Resolution: Not A Bug

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842317#comment-16842317
 ] 

Daniel Kuppitz edited comment on TINKERPOP-2220 at 5/17/19 5:10 PM:


The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like 
{{simplePath}} ensures that no element appears twice on the current path, 
{{repeat(dedup())}} ensures that no element is visited twice within the 
repetition.

{code}
gremlin> g.V(1).repeat(both().simplePath()).emit().path()
==>[v[1],v[3]]
==>[v[1],v[2]]
==>[v[1],v[4]]
==>[v[1],v[3],v[4]]
==>[v[1],v[3],v[6]]
==>[v[1],v[4],v[5]]
==>[v[1],v[4],v[3]]
==>[v[1],v[3],v[4],v[5]]
==>[v[1],v[4],v[3],v[6]]
{code}

Note, how the two longest paths visit {{v[5]}} and {{v[6]}} in the end 
(although these 2 vertices were already seen in shorter paths. Now watch this:

{code}
gremlin> g.V(1).repeat(both().simplePath().dedup()).emit().path()
==>[v[1],v[3]]
==>[v[1],v[2]]
==>[v[1],v[4]]
==>[v[1],v[3],v[6]]
==>[v[1],v[4],v[5]]
{code}

{{dedup()}} inside {{repeat()}} makes sure that this doesn't happen. In other 
cases, you don't really need to worry about deduplication; if two traversers 
hit the same element, they will merge. Thus, from a performance and memory 
perspective, it makes no difference if an element appears once or a thousand 
times within {{repeat()}}.


was (Author: dkuppitz):
The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like 
{{simplePath}} ensures that no element appears twice on the current path, 
{{repeat(dedup())}} ensures that no element is visited twice within the 
repetition.

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842317#comment-16842317
 ] 

Daniel Kuppitz commented on TINKERPOP-2220:
---

The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like 
{{simplePath}} ensures that no element appears twice on the current path, 
{{repeat(dedup())}} ensures that no element is visited twice within the 
repetition.

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: The Bytecode Pattern-Matching Model

[Marko Rodriguez]

Hi,

Thanks for your question. 

I suppose that a “limit bandwidth”-optimization could be based on the provider 
looking at all the instructions in the submitted instruction and then use that 
information to constrain what bytecode patterns it exposes. A simple 
ProviderStrategy would be the means of doing that.

Perhaps showing you what I think the Tuple API should look like would help. 
This API would represent the primary way in which the TP VM interacts with the 
structure/ provider. Thus, this is for all cookies in the cookie jar!



public interface Tuple extends Iterator> {

  public boolean hasKey(Object key);
  public boolean hasValue(Object value);
  public  Tuple get(Object key);
  public A value();
  public long count();
  public boolean hasNext();
  public Tuple next();

  public boolean match(Instruction instruction);
  public Tuple apply(Instruction instruction);
  
}



Structure neo4j = Neo4jStructureFactory.open(config1)
Tuple db = neo4j.root(); 
  => { type:graph | [V] }#1

//

Let a = 

{ type:vertex, name:marko, age:29 | [inE] [outE] }#1

a.count()   => 1
a.value()   => 
Map.of('type','vertex','name','marko','age',29)
a.get('type')   => { 'vertex' }#1
a.get('name')   => { 'marko' }#1
a.hasKey('blah')=> false
a.match(Instruction.of('outE')) => true

//

b = a.apply(Instruction.of('outE’))

{ type:edge, label:?string | [outV] [inV] }#?

b.count()  => -1
b.hasKey('weight') => null// not false because all we 
know is type:edge & label:?string about #? of things.
b.hasKey('type')   => true
b.hasKey('label')  => true
b.get('label') => { ?string }#?   // ?string is something like 
Unknown.of(Type.string())

//

c = b.apply(Instruction.of('inV'))

{ type:vertex }#?

c.count()  => -1
c.value()  => Map.of('type','vertex')
c.hasNext()=> true
c.next()   => { type:vertex, name:stephen, age:17 | [inE] [outE] }
c.hasNext()=> true
c.next()   => { type:vertex, name:kuppitz | [inE] [outE] }
c.hasNext()=> false
c.count()  => 0

//

d = { type:vertex, name:kuppitz | [inE] [outE] }

e = d.get('name')

{ kuppitz }#1

e.count() => 1
e.value() => 'kuppitz'

//

Let f = 

{ type:edge | [outV] [inV] [has,label,eq,?0] }?10

f.count()=> 10
f.get('type')=> { 'edge' }#10
f.match(Instruction.of('has','label',P.eq,'knows'))  => true

//

g = f.apply(Instruction.of('has','label',P.eq,'knows'))

{ type:edge, label:knows | [outV] [inV] }#1

g.count()  => 1
g.hasNext()=> true
g.next()   => { type:edge, label:knows | [outV] [inV] }#1  // its iteration 
is itself!
g.hasNext()=> false// g lost the 
reference
g.count()  => 0

//

Cool? Questions?

Thanks,
Marko.

http://rredux.com 




> On May 17, 2019, at 6:57 AM, Stephen Mallette  wrote:
> 
> This is a nicely refined representation of this concept. I think I've
> followed this abstractly since you first started discussing it, but I've
> struggled with the implementation of it and how it would best work (which
> is probably the reason I keep thinking that I"m not following the
> abstraction hehe). You nicely wrote this from the perspective of the
> individual providers which I think connected me more to the more concrete
> aspect of things, which leads me to this question:  Does the provider send
> the instructions by looking at the query or do they just provide all the
> possible instructions and TP figures it out? (i feel like i've kinda read
> it both ways at different times).
> 
> On Fri, May 17, 2019 at 8:12 AM Marko Rodriguez  >
> wrote:
> 
>> Hello,
>> 
>> This email is primarily for Kuppitz and Josh. Kuppitz offered me his
>> attention yesterday. I explained to him an idea I’ve been working on this
>> week. I’ve been frustrated lately because emails and IM are so hard to
>> express abstract ideas. Fortunately, Kuppitz was patient with me. Then he
>> got it. Then he innovated on it. I was elated.
>> 
>>https://twitter.com/twarko/status/1129117666910674944 
>>  <
>> https://twitter.com/twarko/status/1129117666910674944 
>> >
>> 
>> Josh was interested in what this was all about. I had to go to leave for
>> hockey, but I gave him a fast break down. He sorta got the vibe, but wanted
>> to know more…..
>> 
>> 
>> 
>> There is only one type of “tuple.”
>> 
>> { }#?
>> 
>> The notation says: there are objects, but I don’t know how many of them
>> there are…..if you want to k

[jira] [Commented] (TINKERPOP-2217) Race condition in Gremlin.net driver connection

[Daniel C. Weber (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842190#comment-16842190
 ] 

Daniel C. Weber commented on TINKERPOP-2217:


Revised the PR.

> Race condition in Gremlin.net driver connection
> ---
>
> Key: TINKERPOP-2217
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2217
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.4.1
>Reporter: Daniel C. Weber
>Priority: Critical
>
> In Connection.cs, _writeInProgress could be observed by BeginSendingMessages 
> to indicate that the loop in SendMessagesFromQueueAsync is still "in flight" 
> while in reality, it has already exited. While probably extremly rare, it's 
> still a race condition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: The Bytecode Pattern-Matching Model

[Stephen Mallette]

This is a nicely refined representation of this concept. I think I've
followed this abstractly since you first started discussing it, but I've
struggled with the implementation of it and how it would best work (which
is probably the reason I keep thinking that I"m not following the
abstraction hehe). You nicely wrote this from the perspective of the
individual providers which I think connected me more to the more concrete
aspect of things, which leads me to this question:  Does the provider send
the instructions by looking at the query or do they just provide all the
possible instructions and TP figures it out? (i feel like i've kinda read
it both ways at different times).

On Fri, May 17, 2019 at 8:12 AM Marko Rodriguez 
wrote:

> Hello,
>
> This email is primarily for Kuppitz and Josh. Kuppitz offered me his
> attention yesterday. I explained to him an idea I’ve been working on this
> week. I’ve been frustrated lately because emails and IM are so hard to
> express abstract ideas. Fortunately, Kuppitz was patient with me. Then he
> got it. Then he innovated on it. I was elated.
>
> https://twitter.com/twarko/status/1129117666910674944 <
> https://twitter.com/twarko/status/1129117666910674944>
>
> Josh was interested in what this was all about. I had to go to leave for
> hockey, but I gave him a fast break down. He sorta got the vibe, but wanted
> to know more…..
>
> 
>
> There is only one type of “tuple.”
>
> { }#?
>
> The notation says: there are objects, but I don’t know how many of them
> there are…..if you want to know more, iterate.
>
> 
>
> Let us begin..
>
>
> ——TP4 WITH PROVIDER A——
>
> g.
>
> { [V] }#1
>
> There is one object. Thus, what you see is all that I know about this
> object. In particular, what I know is that it can be mapped via the
> bytecode instruction [V].
>
> Let us apply [V].
>
> { name:?string | [has,age,?0,?1] [has,id,eq,?0] }#?
>
> There are some number of objects. If you want to know what they are,
> iterate. However, I am aware of a feature that they all share. I do know
> for a fact (by the way I was designed by my creator ProviderA) that every
> one of the objects has a name-key to some string value. Also, two has()
> bytecode patterns are available.
>
> Let us apply [hasKey,name].
>
> { name:?string | [has,age,?0,?1] [has,id,eq,?0] }#?
>
> The instruction didn't match any of the available bytecode patterns. Thus,
> the instruction has to evaluated. Did you need to iterate and filter out
> those that don’t have a name-key? No. As I told you, I know that every one
> of the objects has a name-key.
>
> Let us apply [has,id,eq,1].
>
> { name:marko, age:29 | [inE] [outE] }#1
>
> There is one thing. It has primitive key/value data —  a name and an age.
>
> Let us apply [values,name].
>
> { marko }#1
>
> That bytecode instruction didn't match any the available bytecode
> patterns. The instruction was evaluated and there is one thing: the string
> “marko.”
>
> We did:
>
> g.V().hasKey(‘name’).hasId(1).values(‘name’)
>
> The query you provided used an index on id. How do we know that? You
> didn’t have to iterate all the objects and filter on id. I was able to jump
> from all vertices to the one with id=1.
>
> ——TP4 WITH PROVIDER B——
>
> { type:person, name:?string, age:?int | [has,name,eq,?0] }?10
>
> There are 10 objects. Some providers can’t determine how many objects
> there are without full iteration. But, by the way I was designed, I know. I
> also know that all the object have a type:person key/value. I also know
> they all have a name-key and int-key with known value types.
>
> What am I?
>
> CREATE TABLE people {
>   name varchar(100),
>   age int
> }
> CREATE INDEX people_name_idx ON people (name);
>
> ——TP4 WITH PROVIDER C——
>
> g.V().has(‘name’,’marko’).has(‘age’,gt(20)).id()
>
> This is easy. My creator, ProviderC, provides multi-key indices. And when
> the database instance was created, a (name,age)-index was created. Also,
> because you only want the id of those vertices named marko whose age is
> greater than 20, I don’t have to manifest the vertices, I can simply get
> the id out of the index. This is what I provided for each instruction of
> your query...
>
> 1. { type:graph | [V] }#1
> 2. { type:vertex | [has,name,eq,?0] [has,age,?0,?1] [id] }#?
> 3. { type:vertex, label:person, name:marko | [has,age,?0,?1] [id] }#?
> 4. { type:vertex, label:person, name:marko, age:gt(20) | [id] }#?
> 5. { type:int }#?
>
> Unlike ProviderA, all the objects in me have a type-key. It is just
> something I like to do. Call it my quirk. Thus, on line #2, I know that
> there are some number of vertex objects. And do you see my multi-property
> index there? On line #3, I know for a fact that every one of those objects
> has a name:marko entry. Finally, by line #5, I don’t know how many
> id-objects there are, but I do know they are all integers. If you want to
> know what

[jira] [Commented] (TINKERPOP-2217) Race condition in Gremlin.net driver connection

[Jorge Bay (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842144#comment-16842144
 ] 

Jorge Bay commented on TINKERPOP-2217:
--

For me, the path of least resistance would be to include a fix for the current 
issue in this release as proposed here (3 lines of code): 
https://github.com/apache/tinkerpop/pull/1114#issuecomment-492962272

and then, discuss alternative approaches like discussed in 
https://github.com/apache/tinkerpop/pull/1115 for the next iteration.

> Race condition in Gremlin.net driver connection
> ---
>
> Key: TINKERPOP-2217
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2217
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.4.1
>Reporter: Daniel C. Weber
>Priority: Critical
>
> In Connection.cs, _writeInProgress could be observed by BeginSendingMessages 
> to indicate that the loop in SendMessagesFromQueueAsync is still "in flight" 
> while in reality, it has already exited. While probably extremly rare, it's 
> still a race condition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

The Bytecode Pattern-Matching Model

[Marko Rodriguez]

Hello,

This email is primarily for Kuppitz and Josh. Kuppitz offered me his attention 
yesterday. I explained to him an idea I’ve been working on this week. I’ve been 
frustrated lately because emails and IM are so hard to express abstract ideas. 
Fortunately, Kuppitz was patient with me. Then he got it. Then he innovated on 
it. I was elated.

https://twitter.com/twarko/status/1129117666910674944 


Josh was interested in what this was all about. I had to go to leave for 
hockey, but I gave him a fast break down. He sorta got the vibe, but wanted to 
know more…..



There is only one type of “tuple.”

{ }#?

The notation says: there are objects, but I don’t know how many of them there 
are…..if you want to know more, iterate.



Let us begin..


——TP4 WITH PROVIDER A——

g.

{ [V] }#1

There is one object. Thus, what you see is all that I know about this object. 
In particular, what I know is that it can be mapped via the bytecode 
instruction [V].

Let us apply [V].

{ name:?string | [has,age,?0,?1] [has,id,eq,?0] }#?

There are some number of objects. If you want to know what they are, iterate. 
However, I am aware of a feature that they all share. I do know for a fact (by 
the way I was designed by my creator ProviderA) that every one of the objects 
has a name-key to some string value. Also, two has() bytecode patterns are 
available.

Let us apply [hasKey,name]. 

{ name:?string | [has,age,?0,?1] [has,id,eq,?0] }#?

The instruction didn't match any of the available bytecode patterns. Thus, the 
instruction has to evaluated. Did you need to iterate and filter out those that 
don’t have a name-key? No. As I told you, I know that every one of the objects 
has a name-key.

Let us apply [has,id,eq,1]. 

{ name:marko, age:29 | [inE] [outE] }#1

There is one thing. It has primitive key/value data —  a name and an age. 

Let us apply [values,name]. 

{ marko }#1

That bytecode instruction didn't match any the available bytecode patterns. The 
instruction was evaluated and there is one thing: the string “marko.”

We did: 

g.V().hasKey(‘name’).hasId(1).values(‘name’)

The query you provided used an index on id. How do we know that? You didn’t 
have to iterate all the objects and filter on id. I was able to jump from all 
vertices to the one with id=1.

——TP4 WITH PROVIDER B——

{ type:person, name:?string, age:?int | [has,name,eq,?0] }?10

There are 10 objects. Some providers can’t determine how many objects there are 
without full iteration. But, by the way I was designed, I know. I also know 
that all the object have a type:person key/value. I also know they all have a 
name-key and int-key with known value types.

What am I?

CREATE TABLE people {
  name varchar(100),
  age int
}
CREATE INDEX people_name_idx ON people (name);

——TP4 WITH PROVIDER C——

g.V().has(‘name’,’marko’).has(‘age’,gt(20)).id()

This is easy. My creator, ProviderC, provides multi-key indices. And when the 
database instance was created, a (name,age)-index was created. Also, because 
you only want the id of those vertices named marko whose age is greater than 
20, I don’t have to manifest the vertices, I can simply get the id out of the 
index. This is what I provided for each instruction of your query...

1. { type:graph | [V] }#1
2. { type:vertex | [has,name,eq,?0] [has,age,?0,?1] [id] }#?
3. { type:vertex, label:person, name:marko | [has,age,?0,?1] [id] }#?
4. { type:vertex, label:person, name:marko, age:gt(20) | [id] }#?
5. { type:int }#?

Unlike ProviderA, all the objects in me have a type-key. It is just something I 
like to do. Call it my quirk. Thus, on line #2, I know that there are some 
number of vertex objects. And do you see my multi-property index there? On line 
#3, I know for a fact that every one of those objects has a name:marko entry. 
Finally, by line #5, I don’t know how many id-objects there are, but I do know 
they are all integers. If you want to know what they are, iterate.

Below are the possible "bytecode pattern”-paths that are available off of the 
graph object. At any point through this pattern, you could iterate.

[V]
   / | \ 
  / [id]\
 /   \
  [has,name,eq,?0][has,age,?0,?1]
 / \ /  \
/   \   /\
[has,age,?0,?1][id][has,name,eq,?0]  [id]
   |  |
  [id]   [id]


*** In case the diagram above looks weird in your mail client: 
https://gist.github.com/okram/f7f20a3c33aa7caca7c28e85fd16be3f 


——TP4 WITH PROVIDER D——

I support "vertex-centric indices.” For certain queries, I don’t have to 
manifest/iterate the incident edges of a vertex to ch

[jira] [Commented] (TINKERPOP-2217) Race condition in Gremlin.net driver connection

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842125#comment-16842125
 ] 

stephen mallette commented on TINKERPOP-2217:
-

I just wanted to point out that code freeze starts at the end of the day today 
(though it's ok to merge next week if there is agreement that this change is 
stable). I'll leave it to [~Florian Hockmann] and [~jorgebg] to decide if this 
is a safe for merge at this late stage or if it should push off to next 
release. 

> Race condition in Gremlin.net driver connection
> ---
>
> Key: TINKERPOP-2217
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2217
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.4.1
>Reporter: Daniel C. Weber
>Priority: Critical
>
> In Connection.cs, _writeInProgress could be observed by BeginSendingMessages 
> to indicate that the loop in SendMessagesFromQueueAsync is still "in flight" 
> while in reality, it has already exited. While probably extremly rare, it's 
> still a race condition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-2089) Javascript DSL support

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-2089.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.4.2
   3.3.7

> Javascript DSL support
> --
>
> Key: TINKERPOP-2089
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2089
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Affects Versions: 3.3.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.3.7, 3.4.2
>
>
> Javascript needs DSL support which means adding support for constructor 
> injection (passing the class constructor to {{traversal()}} method. For now 
> the workaround would be to monkey patch {{GraphTraversal}} and/or 
> {{GraphTraversalSource}} which isn't so nice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2089) Javascript DSL support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842119#comment-16842119
 ] 

ASF GitHub Bot commented on TINKERPOP-2089:
---

spmallette commented on pull request #1112: TINKERPOP-2089 Added DSL support to 
gremlin-javascript
URL: https://github.com/apache/tinkerpop/pull/1112
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Javascript DSL support
> --
>
> Key: TINKERPOP-2089
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2089
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Affects Versions: 3.3.4
>Reporter: stephen mallette
>Priority: Major
>
> Javascript needs DSL support which means adding support for constructor 
> injection (passing the class constructor to {{traversal()}} method. For now 
> the workaround would be to monkey patch {{GraphTraversal}} and/or 
> {{GraphTraversalSource}} which isn't so nice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)