Hi,
The way I saw it is that the big difference is that graph's have
reified joins. This is both a blessing and a curse.
A blessing because its much easier (less text to type, less mistakes,
clearer semantics...) to traverse an edge than to construct a manual
join.A curse because there are almost always far more ways to traverse
a data set than just by the edges some architect might have considered
when creating the data set. Often the architect is not the domain
expert and the edges are a hardcoded layout of the dataset, which
almost certainly won't survive the real world's demands. In graphs, if
their are no edges then the data is not reachable, except via indexed
lookups. This is the standard engineering problem of database design,
but it is important and useful that data can be traversed, joined,
without having reified edges.
In Sqlg at least, but I suspect it generalizes, I want to create the
notion of a "virtual edge". Which in meta data describes the join and
then the standard to(direction, "virtualEdgeName") will work.
In a way this is precisely to keep the graphy nature of gremlin, i.e.
traversing edges, and avoid using the manual join syntax you described.
CheersPieter
On Thu, 2019-04-18 at 14:15 -0600, Marko Rodriguez wrote:
> Hi,
> *** This is mainly for Kuppitz, but if others care.
> Was thinking last night about relational data and Gremlin. The T()
> step returns all the tables in the withStructure() RDBMS database.
> Tables are ‘complex values’ so they can't leave the VM (only a simple
> ‘toString’).
> Below is a fake Gremlin session. (and these are just ideas…) tables
> -> a ListLike of rows rows -> a MapLike of primitives
> gremlin> g.T()==>t[people]==>t[addresses]gremlin>
> g.T(‘people’)==>t[people]gremlin>
> g.T(‘people’).values()==>r[people:1]==>r[people:2]==>r[people:3]greml
> in>
> g.T(‘people’).values().asMap()==>{name:marko,age:29}==>{name:kuppitz,
> age:10}==>{name:josh,age:35}gremlin>
> g.T(‘people’).values().has(‘age’,gt(20))==>r[people:1]==>r[people:3]g
> remlin>
> g.T(‘people’).values().has(‘age’,gt(20)).values(‘name’)==>marko==>jos
> h
> Makes sense. Nice that values() and has() generally apply to all
> ListLike and MapLike structures. Also, note how asMap() is the
> valueMap() of TP4, but generalizes to anything that is MapLike so it
> can be turned into a primitive form as a data-rich result from the
> VM.
> gremlin> g.T()==>t[people]==>t[addresses]gremlin>
> g.T(‘addresses’).values().asMap()==>{name:marko,city:santafe}==>{name
> :kuppitz,city:tucson}==>{name:josh,city:desertisland}gremlin>
> g.join(T(‘people’).as(‘a’),T(‘addresses’).as(‘b’)). by(se
> lect(‘a’).value(’name’).is(eq(select(‘b’).value(’name’))).
> values().asMap()==>{a.name:marko,a.age:29,b.name:marko,b.city:santafe
> }==>{a.name:kuppitz,a.age:10,b.name:kuppitz,b.city:tucson}==>{a.name:
> josh,a.age:35,b.name:josh,b.city:desertisland}gremlin>
> g.join(T(‘people’).as(‘a’),T(‘addresses’).as(‘b’)). by(’n
> ame’). // shorthand for equijoin on name
> column/key values().asMap()==>{a.name:marko,a.age:29,b.name
> :marko,b.city:santafe}==>{a.name:kuppitz,a.age:10,b.name:kuppitz,b.ci
> ty:tucson}==>{a.name:josh,a.age:35,b.name:josh,b.city:desertisland}gr
> emlin>
> g.join(T(‘people’).as(‘a’),T(‘addresses’).as(‘b’)). by(’n
> ame’)==>t[people<-name->addresses] // without asMap(), just the
> complex value ‘toString'gremlin>
> And of course, all of this is strategized into a SQL call so its
> joins aren’t necessarily computed using TP4-VM resources.
> Anywho — what I hope to realize is the relationship between “links”
> (graph) and “joins” (tables). How can we make (bytecode-wise at
> least) RDBMS join operations and graph traversal operations ‘the
> same.’?
> Singleton: Integer, String, Float, Double, etc. Collection:
> List, Map (Vertex, Table, Document) Linkable: Vertex, Table
> Vertices and Tables can be “linked.” Unlike Collections, they don’t
> maintain a “parent/child” relationship with the objects they
> reference. What does this mean……….?
> Take care,Marko.
> http://rredux.com <http://rredux.com/>
>
>
>
