Re: N-Tuples, Pointers, Data Model Interfaces, and Bytecode Instructions

[Joshua Shinavier]

Let me get back to you in a couple of days (post- Knowledge Graph
Conference) with a more detailed reply, but I think we are more or less on
the same page w.r.t. "pointers". With respect to sequences, in terms of
type theory you can think of them as recursive types which make use of the
disjoint union I have been pushing for. You can also think of them as a
union of tuple types. E.g. the type of a list of strings is

() + (String) + (String, String) + (String, String, String) etc.

You need that + operator to unify tuple types and sequences in this way.

I think of your Pointer as a reference to an entity. It does not contain
the entity it refers to, but it contains the primary key of that entity. If
you assume that primary keys are unique for a given type of entity (another
way of saying that there is only one relation for each entity type), then
the primary key uniquely resolves to a tuple. Otherwise, Pointer is similar
to any other value. Say we use Value for data-typed values. Using your
Pair, the type of an "age" property would look like:

Pair, Value>

Here, I have invented an Entity class to indicate that the pointer resolves
to a vertex (an entity without a tuple, or rather with a 0-tuple -- the
unit element).

Josh




On Mon, May 6, 2019 at 9:38 PM Marko Rodriguez  wrote:

> Hey Josh,
>
> > I am feeling the tuples... as long as they can be typed, e.g.
> >
> >  myTuple.get(Integer) -- int-indexed tuples
> >  myTuple.get(String) -- string-indexed tuples
> > In most programming languages, "tuples" are not lists, though they are
> typed by a list of element types. E.g. in Haskell you might have a tuple
> with the type
> > (Double, Double, Bool)
>
>
> Yes, we have Pair, Triple, Quadruple, etc. However
> for base Tuple of unknown length, the best I can do in Java is . :|
> You can see my stubs in the gist:
> https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8 <
> https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8> (LINES
> #21-42)
>
> > If this is in line with your proposal, then we agree that tuples should
> be the atomic unit of data in TP4.
>
> Yep. Vertices, Edges, Rows, Documents, etc. are all just tuples. However,
> I suspect that we will disagree on some of my tweaks. Thus, I’d really like
> to get your feedback on:
>
> 1. pointers (tuple entries referencing tuples).
> 2. sequences (multi-value tuple entries).
> 3. # hidden map keys :|
> - sorta ghetto.
>
> Also, I’m still not happy with db().has().has().as(‘x’).db().where()… its
> an intense syntax and its hard to strategize.
>
> I really want to nail down this “universal model” (tuple structure and
> tuple-oriented instructions) as then I can get back on the codebase and
> start to flush this stuff out with confidence.
>
> See ya,
> Marko.
>
> http://rredux.com 
>
>
> >
> > Josh
> >
> >
> > On Mon, May 6, 2019 at 5:34 PM Marko Rodriguez  > wrote:
> > Hi,
> >
> > I spent this afternoon playing with n-tuples, pointers, data model
> interfaces, and bytecode instructions.
> >
> > https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8 <
> https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8> <
> https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8 <
> https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8>>
> >
> > *** Kuppitz: They are tuples :). A Map extends Tuple>.
> Tada!
> >
> > What I like about this is that it combines the best of both worlds
> (Josh+Marko).
> > * just flat tuples of arbitrary length.
> > * pattern matching for arbitrary joins. (k1=k2 AND k3=k4
> …)
> > * pointers chasing for direct links. (edges, foreign
> keys, document _id references, URI resolutions, …)
> > * sequences are a special type of tuple used for multi-valued
> entries.
> > * has()/values()/etc. work on all tuple types! (maps, lists,
> tuples, vertices, edges, rows, statements, documents, etc.)
> >
> > Thoughts?,
> > Marko.
> >
> > http://rredux.com   http://rredux.com/>>
> >
> >
>
>

Re: N-Tuples, Pointers, Data Model Interfaces, and Bytecode Instructions

[Marko Rodriguez]

Hey Josh,

> I am feeling the tuples... as long as they can be typed, e.g.
> 
>  myTuple.get(Integer) -- int-indexed tuples
>  myTuple.get(String) -- string-indexed tuples
> In most programming languages, "tuples" are not lists, though they are typed 
> by a list of element types. E.g. in Haskell you might have a tuple with the 
> type
> (Double, Double, Bool)


Yes, we have Pair, Triple, Quadruple, etc. However for 
base Tuple of unknown length, the best I can do in Java is . :| You can 
see my stubs in the gist:
https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8 
 (LINES #21-42)

> If this is in line with your proposal, then we agree that tuples should be 
> the atomic unit of data in TP4.

Yep. Vertices, Edges, Rows, Documents, etc. are all just tuples. However, I 
suspect that we will disagree on some of my tweaks. Thus, I’d really like to 
get your feedback on:

1. pointers (tuple entries referencing tuples).
2. sequences (multi-value tuple entries).
3. # hidden map keys :|
- sorta ghetto.

Also, I’m still not happy with db().has().has().as(‘x’).db().where()… its an 
intense syntax and its hard to strategize. 

I really want to nail down this “universal model” (tuple structure and 
tuple-oriented instructions) as then I can get back on the codebase and start 
to flush this stuff out with confidence.

See ya,
Marko.

http://rredux.com 


> 
> Josh
> 
> 
> On Mon, May 6, 2019 at 5:34 PM Marko Rodriguez  > wrote:
> Hi,
> 
> I spent this afternoon playing with n-tuples, pointers, data model 
> interfaces, and bytecode instructions.
> 
> https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8 
>  
>  >
> 
> *** Kuppitz: They are tuples :). A Map extends Tuple>. Tada!
> 
> What I like about this is that it combines the best of both worlds 
> (Josh+Marko).
> * just flat tuples of arbitrary length.
> * pattern matching for arbitrary joins. (k1=k2 AND k3=k4 …)
> * pointers chasing for direct links. (edges, foreign keys, 
> document _id references, URI resolutions, …)
> * sequences are a special type of tuple used for multi-valued entries.
> * has()/values()/etc. work on all tuple types! (maps, lists, tuples, 
> vertices, edges, rows, statements, documents, etc.)
> 
> Thoughts?,
> Marko.
> 
> http://rredux.com   >
> 
> 

[jira] [Closed] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed

[Chris Hupman (JIRA)]

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

Chris Hupman closed TINKERPOP-2209.
---
Resolution: Won't Fix

Actually ended up being a duplicate of issue 1048 after further analysis.

 

Opened up an [issue in 
JanusGraph|[https://github.com/JanusGraph/janusgraph/issues/1554]] to resolve 
this. 

> hasId is not converting properly when multiple values are passed
> 
>
> Key: TINKERPOP-2209
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3
> Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
>Reporter: Chris Hupman
>Priority: Minor
>
> While [trying to answer a question on Stack Overflow 
> |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
>  I found that hasId is performing `~id.eq` against arrays instead of 
> `~id.within` For a workaround the user reporting the issue found that quoting 
> the values or converting them to longs worked. 
>  
> ```
> {{ids = [8440,12536]}}
> {{paths = 
> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}
> {{paths = 
> g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}
> ```



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

N-Tuples, Pointers, Data Model Interfaces, and Bytecode Instructions

[Marko Rodriguez]

Hi,

I spent this afternoon playing with n-tuples, pointers, data model interfaces, 
and bytecode instructions.

https://gist.github.com/okram/25d50724da89452853a3f4fa894bcbe8 


*** Kuppitz: They are tuples :). A Map extends Tuple>. Tada!

What I like about this is that it combines the best of both worlds (Josh+Marko).
* just flat tuples of arbitrary length.
* pattern matching for arbitrary joins. (k1=k2 AND k3=k4 …)
* pointers chasing for direct links. (edges, foreign keys, 
document _id references, URI resolutions, …)
* sequences are a special type of tuple used for multi-valued entries.
* has()/values()/etc. work on all tuple types! (maps, lists, tuples, 
vertices, edges, rows, statements, documents, etc.)

Thoughts?,
Marko.

http://rredux.com 

[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2209:
---

This is a known issue: https://issues.apache.org/jira/browse/TINKERPOP-1048

Unfortunately, I don't think we can change that. TinkerPop itself ignores 
numeric data types (meaning, an Integer 1 is considered equal to a Long 1). But 
when it comes to the graph step, it's really up to the provider, e.g. how he 
decides to translate the provided input variables to a backend query.

I'm not entirely sure about it, but my guess is, that there are 2 different 
code paths in {{JanusGraphStep}} / {{JanusGraphStepStrategy}} - one of them 
converts the Integers, the other doesn't.

> hasId is not converting properly when multiple values are passed
> 
>
> Key: TINKERPOP-2209
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3
> Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
>Reporter: Chris Hupman
>Priority: Minor
>
> While [trying to answer a question on Stack Overflow 
> |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
>  I found that hasId is performing `~id.eq` against arrays instead of 
> `~id.within` For a workaround the user reporting the issue found that quoting 
> the values or converting them to longs worked. 
>  
> ```
> {{ids = [8440,12536]}}
> {{paths = 
> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}
> {{paths = 
> g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}
> ```



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

[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed

[Chris Hupman (JIRA)]

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

Chris Hupman commented on TINKERPOP-2209:
-

Thanks for the info Daniel. I have a better understanding of what was causing 
the issue now after some additional testing.  I'm still seeing an issue, but 
hopefully I can frame it better now.

Even if you surround ids with a within() step or append toArray() you won't get 
any actual results. 
{code:java}
 gremlin> ids = 
[4112,4128,4136,8232,12328,16424,20520,4296,4328,4344,8440,12536]
==>4112
==>4128
==>4136
==>8232
==>12328
==>16424
==>20520
==>4296
==>4328
==>4344
==>8440
==>12536
gremlin> paths = 
g.V(ids).until(hasId(within(ids))).repeat(bothE().otherV().simplePath()).path().limit(5)
gremlin>
{code}
but I did get results when I generated the id like this
{code:java}
gremlin> ids = g.V().id().toList()
12:47:28 WARN  org.janusgraph.graphdb.transaction.StandardJanusGraphTx  - Query 
requires iterating over all vertices [()]. For better performance, use indexes
==>4112
==>4128
==>4136
==>8232
==>12328
==>16424
==>20520
==>4296
==>4328
==>4344
==>8440
==>12536
gremlin> 
g.V(ids).until(hasId(within(ids))).repeat(bothE().otherV().simplePath()).path().limit(5)
==>[v[4112]]
==>[v[4128]]
==>[v[4136]]
==>[v[8232]]
==>[v[12328]]
{code}
It works because the array is being populated with Longs instead of ints. The 
real issue the user was having is that hasId GraphStep isn't converting the 
values to Longs, but g.V(ids) will convert them, creating confusion.

I've only really looked through the JanusGraph/Titan source, but my 
understanding is that vertex ids are always longs. It think the bug should be 
framed as hasId should try to convert ints to Longs. Strings are already 
properly converted.

> hasId is not converting properly when multiple values are passed
> 
>
> Key: TINKERPOP-2209
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3
> Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
>Reporter: Chris Hupman
>Priority: Minor
>
> While [trying to answer a question on Stack Overflow 
> |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
>  I found that hasId is performing `~id.eq` against arrays instead of 
> `~id.within` For a workaround the user reporting the issue found that quoting 
> the values or converting them to longs worked. 
>  
> ```
> {{ids = [8440,12536]}}
> {{paths = 
> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}
> {{paths = 
> g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}
> ```



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

[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2209:
---

This is the expected behavior. {{hasId}} accepts varargs; a collection is a 
single argument, thus it will be translated into {{eq()}}. However, if you pass 
an array, it will be translated into {{within}}.
  
{code:java}
gremlin> ids = [8440,12536]
==>8440
==>12536
gremlin> 
g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().toString()[0..<100]
==>[GraphStep(vertex,[8440, 12536]), RepeatStep(until([HasStep([~id.eq([8440, 
12536])])]),[VertexStep(O
gremlin> ids = [8440,12536].toArray()
==>8440
==>12536
gremlin> 
g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().toString()[0..<100]
==>[GraphStep(vertex,[8440, 12536]), 
RepeatStep(until([HasStep([~id.within([8440, 12536])])]),[VertexSt
{code}
{{g.V(ids)}} returns all vertices, because {{GraphStep}} is the only step that 
unfolds collections internally. {{g.V().hasId(ids)}} returns all vertices, 
because in this case, {{hasId}} gets folded into {{GraphStep}}. Theoretically, 
we could remove the automatic unfolding in {{GraphStep}}, but practically, this 
would be a major breaking change. Likewise, we can't do the automatic unfolding 
for every other step, as you wouldn't be able to actually test for equal 
collections anymore.

> hasId is not converting properly when multiple values are passed
> 
>
> Key: TINKERPOP-2209
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3
> Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
>Reporter: Chris Hupman
>Priority: Minor
>
> While [trying to answer a question on Stack Overflow 
> |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
>  I found that hasId is performing `~id.eq` against arrays instead of 
> `~id.within` For a workaround the user reporting the issue found that quoting 
> the values or converting them to longs worked. 
>  
> ```
> {{ids = [8440,12536]}}
> {{paths = 
> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}
> {{paths = 
> g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}
> ```



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

[jira] [Created] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed

[Chris Hupman (JIRA)]

Chris Hupman created TINKERPOP-2209:
---

 Summary: hasId is not converting properly when multiple values are 
passed
 Key: TINKERPOP-2209
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.3.3
 Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
Reporter: Chris Hupman


While [trying to answer a question on Stack Overflow 
|[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
 I found that hasId is performing `~id.eq` against arrays instead of 
`~id.within` For a workaround the user reporting the issue found that quoting 
the values or converting them to longs worked. 

 

```

{{ids = [8440,12536]}}

{{paths = 
g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}

{{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}

{{paths = 
g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}

{{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}

```



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

A collection of examples that map a query language query to provider bytecode.

[Marko Rodriguez]

Hello,

I’m experimenting with moving between X query language and Y bytecode via 
Universal Bytecode.

The general (and very difficult) goal of TP4 is to be able to execute queries 
(from any known query language) against any database (regardless of underlying 
data model) using any processing engine.
- e.g. Gremlin over MySQL (as Relational) using RxJava.
- e.g. SQL over Cassandra (as WideColumn) using Flink.
- e.g. SPARQL over MongoDB (as Document) using Akka.
- e.g. Cypher over Neptune (as Graph) using Pipes.
- e.g. ...

——

NOTES:
1. Realize that databases are both processors and structures.
- MySQL has its own SQL engine.
- Cassandra has its own CQL engine.
- MongoDB has its own DocumentQuery engine.
- …
2. What can be processed by the database’s engine should be evaluated 
by the database (typically).
3. What can not be processed by the database’s engine should be 
evaluated by the processor.
4. DATABASE_ENGINE->PROCESSOR->DATABASE_ENGINE->PROCESSOR->etc.
- data may move from database to processor back to database 
back to processor, etc. to yield the final query result.

The universal bytecode chunks in the examples to come assume the following 
n-tuple structure accessible via db():

[0][id:1, label:person, name:marko, outE:*1]
[1][0:*2, 1:*3]
[2][id:7, label:knows, outV:*0, inV:*4]
[3][id:8, label:knows, outV:*0, inV:*5]
[4][id:2, label:person, name:vadas]
[5][id:4, label:person, name:josh]

- All tuples have an id that is outside the id-space of the underlying data 
model.
- Field values can have pointers to other tuples via *-prefix notation.

Every compilation goes:

Query language -> Universal Bytecode -> Data Model Bytecode -> Provider 
Bytecode

——

How do you compile Gremlin to universal bytecode for evaluation over MySQL?

—— GREMLIN QUERY ——

g.V().has(“name”,”marko”).out(“knows”).values(“name”)

—— UNIVERSAL BYTECODE ——

   ==> (using tuple pointers)

db().has(‘label’, within(‘person’,’project’)).
 has(‘name’,’marko’)
  values(‘outE’).has(‘label’,’knows’).
  values(‘inV’).values(‘name’)

—— RELATIONAL BYTECODE ——

   ==>

R(“people”,”projects").has(“name”,”marko”).
 join(R(“knows”)).by(“id”,eq(“outV”)).
 join(R(“people”)).by(“inV”,eq(“id”)).
  values(“name”)

—— JDBC BYTECODE ——

   ==>

union(
  sql(‘SELECT name FROM people as p1, knows, people as p2 WHERE 
p1.id=knows.outV AND knows.inV=p2.id’),
  sql(‘SELECT name FROM projects as p1, knows, projects as p2 WHERE 
p1.id=knows.outV AND knows.inV=p2.id’))

The assumed SQL tables are:

CREATE TABLE people (
id int,
label string, // person
name string,
PRIMARY KEY id
);

CREATE TABLE knows (
id int,
label string, // knows
name string,
outV int,
inV int,
PRIMARY KEY id,
FOREIGN KEY (outV) REFERENCES people(id),
FOREIGN KEY (inV) REFERENCES people(id)
);

There needs to be two mapping specifications (Graph->Universal & 
Universal->Relational)
- V() -> vertex tables are people+projects.
- label() -> plural is table name
- outE -> person.outE.knows is resolved via knows.outV (foreign key to 
person table by id)
- inV -> knows.values(‘inV’) is resolved to person (foreign key to 
person table by id)

Next, we are assuming that a property graph is encoded in MySQL as we have 
outE, inV, etc. column names. If we want to interpret any relational data as 
graph, then it is important to denote which tables are “join tables” and what 
the column-names are for joining. What about when a “join table” references 
more than 2 other rows? (i.e. n-ary relation — hypergraph) ? Is there a general 
solution to looking at any relational schema in terms of a binary property 
graph?

——

How do you compile SQL to universal bytecode for evaluation over Cassandra?

—— SQL QUERY ——

SELECT p2.name FROM people as p1, knows, people as p2 
  WHERE p1.name=marko AND p1.id=knows.outV AND knows.inV=p2.id

—— UNIVERSAL BYTECODE ——

   ==> (using tuple pointers)

db().has(‘label’,’person’).has(‘name’,’marko’).
  values(‘outE’).has(‘label’,’knows’).
  values(‘inV’).values(‘name’)

—— WIDE-COLUMN BYTECODE ——

   ==>

R(‘people’).has(‘name’,’marko’).
  values(‘outE’).has(‘label’,’knows’).values(‘inV’).as(‘$inV’)
R(‘people’).has(‘id’,eq(path(‘$inV’))).values(‘name’)

—— CASSANDRA BYTECODE ——

   ==> 

cql('SELECT outE:knows FROM people WHERE name=marko’).
cql('SELECT name FROM people WHERE id=$inV’).by(‘inV’)

There needs to be a mapping specification from SQL->Universal
- knows.outV is foreign key a person row.
- person.outE.knows is referenced by a knows.outV.

The people-table is is defined as below where each edge is a column.

CREATE TABLE people (
id int,
name string,
age int
outE list>,
PRIMARY KEY (id,name)
);

The last bytecode is chained CQL where each result from 

[jira] [Commented] (TINKERPOP-2143) JavaScript GLV: Support browsers

[Dominik Franek (JIRA)]

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

Dominik Franek commented on TINKERPOP-2143:
---

[~moayad86] Have you tried the code I've developed in the PR mentioned by 
stephen? It would be nice if you also try this. I might be fixing the tests 
which are failing on some dependencies, but you should be able to get it 
running just from the code I pushed to the PR.

> JavaScript GLV: Support browsers
> 
>
> Key: TINKERPOP-2143
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2143
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Reporter: Jorge Bay
>Priority: Minor
> Attachments: query-editor.jpg
>
>
> Currently the JavaScript GLV is designed to work on Node.js runtime.
> We could consider supporting browser runtimes.



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

[jira] [Closed] (TINKERPOP-2204) Client receives no response on failed request

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-2204.
---
   Resolution: Fixed
 Assignee: stephen mallette
Fix Version/s: 3.4.2
   3.3.7

For 3.3.7 fixed via CTR with 
https://github.com/apache/tinkerpop/commit/6a252845c1d0a40e3d177242a4e23b580c49b613

> Client receives no response on failed request
> -
>
> Key: TINKERPOP-2204
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2204
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.1
>Reporter: Divij Vaidya
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.3.7, 3.4.2
>
>
> The current implementation may lead to a client waiting indefinitely from a 
> response from the server. This occurs in cases when the exceptions that 
> occurred while generating status attributes or generating metadata in the 
> TraversalOpProcessor are consumed in the catch block without sending a 
> response back to the client.



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

[jira] [Commented] (TINKERPOP-2204) Client receives no response on failed request

[ASF GitHub Bot (JIRA)]

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

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

spmallette commented on pull request #1102: TINKERPOP-2204 Do not consume the 
exception while generating metadata
URL: https://github.com/apache/tinkerpop/pull/1102
 
 
   
 

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


> Client receives no response on failed request
> -
>
> Key: TINKERPOP-2204
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2204
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.1
>Reporter: Divij Vaidya
>Priority: Major
>
> The current implementation may lead to a client waiting indefinitely from a 
> response from the server. This occurs in cases when the exceptions that 
> occurred while generating status attributes or generating metadata in the 
> TraversalOpProcessor are consumed in the catch block without sending a 
> response back to the client.



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

Re: The Fundamental Structure Instructions Already Exist! (w/ RDBMS Example)

[Marko Rodriguez]

Hey Josh,


> One more thing is needed: disjoint unions. I described these in my email on
> algebraic property graphs. They are the "plus" operator to complement the
> "times" operator in our type algebra. A disjoint union type is just like a
> tuple type, but instead of having values for field a AND field b AND field
> c, an instance of a union type has a value for field a XOR field b XOR
> field c. Let me know if you are not completely sold on union types, and I
> will provide additional motivation.

Huh. That is an interesting concept. Can you please provide examples?

>> The instructions:
>>1. relations can be “queried” for matching tuples.
>> 
> 
> Yes.

One thing I want to stress. The “universal bytecode” is just standard 
[op,arg*]* bytecode save that data access is via the “universal model's" db() 
instruction. Thus, AND/OR/pattern matching/etc. is all available. Likewise 
union(), repeat(), coalesce(), choose(), etc. are all available.

db().and(as('a').values('knows').as('b'),
 or(as('a').has('name','marko'),
as('a').values(‘created').count().is(gt(1))),
 as('b').values(’created').as('c')).
 path(‘c')

As you can see, and()/or() pattern matching is possible and can be nested.
  *** SIDENOTE: In TP3, such nested and()/or() pattern matching is expressed 
using match() where the root grouping is assumed to be and()’d together.
  *** SIDENOTE: In TP4, I want to get rid of an explicit match() bytecode 
instruction and replace it with and()/or() instructions with prefix/suffix 
as()s.
  *** SIDENOTE: In TP4, in general, any nested bytecode that starts with as(x) 
is path(x) and any bytecode that ends with as(y) is where(eq(path(y)).

> 
>>2. tuple values can be projected out to yield primitives.
>> 
> 
> Or other tuples, or tagged values. E.g. any edge projects to two vertices,
> which are (trivial) tuples as opposed to primitive values.

Good point. I started to do some modeling and I’ve been getting some good 
mileage from a new “pointer” primitive. Assume every N-Tuple has a unique ID 
(outside the data models id space). If so, the TinkerPop toy graph as N-Tuples 
is:

[0][id:1,name:marko,age:29,created:*1,knows:*2]
[1][0:*3]
[2][0:*4,1:*5]
[3][id:3,name:lop,lang:java]
[4][id:2,name:vadas,age:27]
[5][id:4,name:josh,age:32,created*:…]

I know you are thinking that vertices don’t have “outE” projections so this 
isn’t inline with your thinking. However, check this out. If we assume that 
pointers are automatically dereferenced on reference then:

db().has(‘name’,’marko’).values(‘knows’).values(‘name’) => vadas, josh

Pointers are useful when a tuple has another tuple as a value. Instead of 
nesting, you “blank node.” DocumentDBs (with nested list/maps) would use this 
extensively.

> Grumble... db() is just an alias for select()... grumble…

select() and project() are existing instructions in TP3 (TP4?).

SELECT
db() will iterate all N-Tuples
has() will filter out those N-Tuples with respective key/values.
and()/or() are used for nested pattern matching.

PROJECT
values() will project out the n-tuple values.

> Here, we are kind of mixing fields with property keys. Yes,
> db().has('name', 'marko') can be used to search for elements of any type...
> if that type agrees with the out-type of the "name" relation. In my
> TinkerPop Classic example, the out type of "name" is (Person OR Project),
> so your query will get you people or projects.

Like indices, I don’t think we should introduce types. But this is up for 
further discussion...

> Which is to say that we define the out-type of "name" to be the disjoint
> union of all element types. The type becomes trivial. However, we can also
> be more selective if we want to, restricting "name" only to a small subset
> of types.

Hm… I’m listening. I’m running into problems in my modeling when trying to 
generically fit things into relational tables. Maybe typing is necessary :(.


> Good idea. TP4 can provide several "flavors" of interfaces, each of which
> is idiomatic for each major class of database provider. Meeting the
> providers halfway will make integration that much easier.

Yes. With respects to graphdb providers, they want to think in terms of 
Vertex/Edges/etc. We want to put the bytecode in their language so:

1. It is easier for them to write custom strategies.
2. inV() can operate on their Vertex object without them having to 
implement inV().
*** Basically just like TP3 is now. GraphDB providers implement 
Graph/Vertex/Edge and everything works! However, they will then want to write 
custom instructions/strategies to do use their databases optimizations such as 
vertex-centric indices for outE(‘knows’).has(‘stars’,gt(3)).inV().


> I think we will see steps like V() and R() in Gremlin, but do not need them
> in bytecode. Again, db() is just select(), V() is just select(), etc. The
> model-specific interfaces