Hello Mike,
Gremlin currently will run that linearly (save for appropriate index lookups),
but in 3.2.0 it will be decomposed using something called a
RuntimeTraversalStrategy.
However, my argument is more about the way in which patterns are expressed, not
how the engine ultimately executes it. For instance, its easy to write a
TraversalStrategy that will convert
g.V.has('name','marko').as('x').out('knows').as('y').select('x','y')
into
g.V.match(
as('x').has('name','marko')
as('x').out('knows').as('y')).select('x','y')
…and subject the traversal to runtime pattern selection based on the set
reduction powers of the various patterns.
Thanks,
Marko.
http://markorodriguez.com
On Nov 3, 2015, at 3:27 PM, Mike Personick <[email protected]> wrote:
> The big advantage that this:
>
> SELECT ?x ?y WHERE { ?x knows ?y . ?x name "marko" . }
>
> Has over this:
>
> g.V.has('name','marko').as('x').out('knows').as('y').select('x','y')
>
> Is that the SPARQL query engine can pick which graph pattern to run first,
> depending on the cardinalities in the graph - i.e. if there are many more
> "knows" relationships than there are elements with name="marko" then it
> makes sense to run (?x name "marko") first and then run (?x knows ?y) with
> ?x bound. And if there are many more elements with name="marko" than there
> are "knows" relationships then the query engine can choose to run the query
> in the opposite order. Declarative query language + cardinality-driven
> query optimization = better scalability / performance.
>
> Please correct me if I'm wrong but the gremlin traversal example will
> always run in the order presented (imperative). I know there is a
> MatchStep now in TP3 that could be used to do what I'm describing above,
> but does that win the "easy to read" contest?
>
> -Mike
>
>
> On Tue, Nov 3, 2015 at 2:18 PM, Rob Vesse <[email protected]> wrote:
>
>> You're overcomplicating the SPARQL example here
>>
>> SELECT ?x ?y WHERE { ?x knows ?y . ?x name "marko" . }
>>
>> No need for FILTER in this example
>>
>> Rob
>>
>>
>>
>> On 02/11/2015 10:24, "Marko Rodriguez" <[email protected]> wrote:
>>
>>> Hi,
>>>
>>>> Gremlin, based on my experience, is a barrier for many people who fall
>>>> into
>>>> category 1 (and even 2 at times).
>>>
>>> With TinkerPop3, I don't see that argument holding anymore. There has
>>> always been this notion in the zeitgeist that Gremlin is "hard to read."
>>> However, when Gremlin3 is compared to Cypher/SQL/SPARL, I don't see it
>>> anymore. Look at the "side-by-side" representations dispersed throughout
>>> https://news.ycombinator.com/item?id=10434372. With the
>>> match()/where()/select()-clauses in Gremlin3, the "SQL"-vibe is there and
>>> I don't see it as being all that complicated (of course I'm not the
>>> person to judge this), moreover, its more "embedded" in the language than
>>> either Cypher/SPARQL/SQL. For instance:
>>>
>>> SELECT ?x, ?y WHERE { ?x knows ?y . ?x name ?z . FILTER(?z ==
>> "marko" } }
>>> SELECT x,y FROM table WHERE x.knows.y AND x.name="marko" //
>> shorthand
>>> MATCH (x)-[:knows]->(y) WHERE x.name = "marko" RETURN x,y
>>>
>>>
>> g.V.has('name','marko').as('x').out('knows').as('y').select('x','y')
>>>
>>> With Gremlin you don't need this "external" WHERE/FILTER notion. Its part
>>> of the walk.
>>>
>>> Anywho…rambling…
>>>
>>> Marko.
>>>
>>> http://markorodriguez.com
>>>
>>>>
>>>> On Wed, Oct 28, 2015 at 9:51 AM, Alaa Mahmoud <[email protected]>
>>>> wrote:
>>>>
>>>>> I was at GraphConnect last week and I attended a Cypher training
>>>>> session
>>>>> (just for the heck of it :-)) I was amazed how easy it was to pick up
>>>>> in a
>>>>> short amount of time. I believe Cypher's Match/Where/Return syntax is a
>>>>> good starting point for those coming from an RDBMS/SQL background and
>>>>> there's a lot of those.
>>>>>
>>>>> Implementing a Cypher driver could make it easier for those with SQL to
>>>>> move or at consider graph as a option.
>>>>>
>>>>> Regards
>>>>> Alaa
>>>>>
>>>>> On Tue, Oct 27, 2015 at 3:05 PM, Ran Magen <[email protected]> wrote:
>>>>>
>>>>>> Hey Marko,
>>>>>>
>>>>>> Gremlin is definitely the best over-all "GQL" around. That's why I
>>>>>> think
>>>>>> that before we develop any language-driver, we need to ask ourselves
>>>>>> if
>>>>>> there's are any use-cases in which that language would be a better
>>>>>> choice
>>>>>> than gremlin.
>>>>>>
>>>>>> - SPARQL - Many people are familiar with SPARQL, so a driver would
>>>>> help
>>>>>> them easily get to work with a TP graph.
>>>>>> - GraphQL - QBE is a great definition. The cool thing about these
>>>>>> queries is that they're very "composable", which is perfect for a
>>>>>> composite
>>>>>> application in which you have deeply nested components, each
>>>>> specifying
>>>>>> its own sub-query (e.g. the standard practice in React UIs). Granted
>>>>>> gremlin is much more powerful, and I'd use it in almost all
>>>>>> applications,
>>>>>> but when building something like a React application, GraphQL could
>>>>>> come on
>>>>>> top.
>>>>>> - OpenCypher - While it's an over-all more "able" language than
>>>>> SPARQL &
>>>>>> GraphQL, I haven't seen any use-case in which it trumps gremlin.
>>>>> That's
>>>>>> why
>>>>>> IMO there is no point in implementing it.
>>>>>>
>>>>>> My 2 cents.
>>>>>> Cheers,
>>>>>> Ran
>>>>>>
>>>>>>
>>>>>> On Tue, 27 Oct 2015 at 02:37 Marko Rodriguez <[email protected]>
>>>>> wrote:
>>>>>>
>>>>>>> Hi Ran,
>>>>>>>
>>>>>>> Here are my thoughts on GraphQL now that I have learned more about
>>>>>>> it.
>>>>>>>
>>>>>>> 1. Matt Frantz and David Robinson nailed it -- its not really
>>>>>>> a
>>>>>>> "graph language." Its more a QBE (query by example -- first time I
>>>>> heard
>>>>>>> that was from Matt).
>>>>>>> - As such, do we want to support it in TinkerPop when
>>>>> we
>>>>>>> can do much more complex queries with the Gremlin machine?
>>>>>>> 2. I think we should try and get the GraphQL guys to implement
>>>>> a
>>>>>>> compiler for Gremlin VM.
>>>>>>> - You said it -- providers have to implement a server
>>>>> to
>>>>>>> execute it. Why not just implement graph.structure API and let the
>>>>>> Gremlin
>>>>>>> VM do the work for you.
>>>>>>> - Is this a Facebook thing? Perhaps someone can find
>>>>>> their
>>>>>>> repository and post a ticket and see where it goes.
>>>>>>>
>>>>>>> The one thing that GraphQL has going for it (like SPARQL) is the ease
>>>>> of
>>>>>>> the development/maintenance of the compiler. Cypher and SQL are going
>>>>> to
>>>>>> be
>>>>>>> insanely complex compilers to implement/maintain -- it will take
>>>>>> manpower.
>>>>>>>
>>>>>>> Marko.
>>>>>>>
>>>>>>> http://markorodriguez.com
>>>>>>>
>>>>>>> On Oct 26, 2015, at 11:49 AM, Ran Magen <[email protected]> wrote:
>>>>>>>
>>>>>>>> I'd be much more interested in GraphQL support.
>>>>>>>> The cool thing about GraphQL is that you can easily create a unified
>>>>>>> "graph
>>>>>>>> query" from different components in an application, while keeping
>>>>>>>> the
>>>>>>>> separation between the components. It's a great feature for
>>>>>>>> composite
>>>>>>> UIs (e.g.
>>>>>>>> React).
>>>>>>>> As I understand it, GraphQL is mostly a standard for graph queries,
>>>>> but
>>>>>>> the
>>>>>>>> user has to implement a server to actually execute the queries. And
>>>>>> what
>>>>>>>> better execution engine than the Gremlin VM?
>>>>>>>>
>>>>>>>> On Mon, 26 Oct 2015 at 15:17 Marko Rodriguez <[email protected]>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hey,
>>>>>>>>>
>>>>>>>>> After reading Stephen's reply, I was like -- "huh, sure." I didn't
>>>>>>> really
>>>>>>>>> don't care one way or another until I just read this:
>>>>>>>>>
>>>>>>>>> http://neo4j.com/blog/open-cypher-sql-for-graphs/
>>>>>>>>>
>>>>>>>>> Look at the tone and lies that Neo4j is portraying.
>>>>>>>>>
>>>>>>>>> * Marko Rodriguez as "just some buddy of Emil's."
>>>>>>>>> * Aurelius is some company. No, its called DataStax.
>>>>>>>>> * Not once is Apache TinkerPop discussed or referenced --
>>>>> "just
>>>>>>>>> Marko and a band of merry 'graphistas'."?!
>>>>>>>>> * DataStax is NOT involved in their efforts for OpenCypher.
>>>>>>>>>
>>>>>>>>> The problem with Neo4j is they are corrupt. They use lies to
>>>>>>>>> control
>>>>>> the
>>>>>>>>> population. If we support Cypher in TinkerPop (like actively put it
>>>>>> into
>>>>>>>>> the repository as a distribution) we will see press releases like:
>>>>>>>>>
>>>>>>>>> * TinkerPop drops Gremlin in favor of Cypher.
>>>>>>>>> * TinkerPop realizes that Cypher is the superior language.
>>>>>>>>> * TinkerPop follows Neo4j in learning how to do graph
>>>>>> processing
>>>>>>>>> the right way.
>>>>>>>>> * etc.
>>>>>>>>>
>>>>>>>>> Its going to be a bunch malarky like that that I don't want
>>>>>> surrounding
>>>>>>>>> our project. It would behoove us to be smart about how we interact
>>>>>> with
>>>>>>>>> people like this as they will use every opportunity they can to
>>>>>> destroy
>>>>>>> our
>>>>>>>>> project to better their economic efforts.
>>>>>>>>>
>>>>>>>>> I don't do lies nor interact with people who use misinformation and
>>>>>>>>> deception to get "ahead,"
>>>>>>>>> Marko.
>>>>>>>>>
>>>>>>>>> http://markorodriguez.com
>>>>>>>>>
>>>>>>>>> On Oct 26, 2015, at 4:35 AM, Stephen Mallette <
>> [email protected]
>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I'd be open to have cypher and sparql as first class citizens of
>>>>> The
>>>>>>>>>> TinkerPop. As I see it, there are two groups of graph users on the
>>>>>>> fringe
>>>>>>>>>> of TinkerPop and they live in the cypher world and in the RDF
>>>>> world.
>>>>>>>>>> Having both of these projects in TinkerPop would allow us to reach
>>>>>> both
>>>>>>>>> of
>>>>>>>>>> those communities. Doing so would help to expand usage and
>>>>>> potentially
>>>>>>>>>> attract more committers.
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 23, 2015 at 1:08 PM, Marko Rodriguez <
>>>>>> [email protected]
>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I (personally) am interested in getting another language into
>>>>>>>>> TinkerPop's
>>>>>>>>>>> distribution. I see an imbalance in the following table:
>>>>>>>>>>>
>>>>>>>>>>> TinkerGraph | Gremlin-Java8
>>>>>>>>>>> Neo4j | Gremlin-Groovy
>>>>>>>>>>> Hadoop | NOTHING
>>>>>>>>>>>
>>>>>>>>>>> That is, we have 3 graph distributions, why not have 3 language
>>>>>>>>>>> distributions. Moreover, I don't want yet another Gremlin-JVMLang
>>>>>>>>> language
>>>>>>>>>>> as that doesn't showcase the virtual machine aspects of Gremlin
>>>>>>>>>>> as
>>>>>>> well
>>>>>>>>> as,
>>>>>>>>>>> for example: SPARQL-Gremlin or SQL-Gremlin.
>>>>>>>>>>>
>>>>>>>>>>> I (personally) am NOT interested in openCypher as the 3rd
>>>>>>>>>>> language
>>>>>>>>>>> distribution for the following 2 reasons:
>>>>>>>>>>>
>>>>>>>>>>> 1. It will be at least a year+ before it culminates into
>>>>>>>>> something.
>>>>>>>>>>> 2. It doesn't fold a different computing space into
>>>>> TinkerPop.
>>>>>>>>>>>
>>>>>>>>>>> To expand on #2, Hadoop is NOT typically seen as a graph system,
>>>>> but
>>>>>>>>> with
>>>>>>>>>>> TinkerPop, we have Hadoop serving as a graph engine. With SPARQL,
>>>>> we
>>>>>>>>> pull
>>>>>>>>>>> in the RDF guys (thats cool). With SQL, we pull in the world. I
>>>>>> sorta
>>>>>>>>>>> prefer SPARQL as its an easy language to handle (thanks in part
>>>>>>>>>>> to
>>>>>>>>> Apache
>>>>>>>>>>> Jena). With SQL we have Apache Calcite offering help, but SQL is
>>>>>>> nasty
>>>>>>>>>>> looking for graph queries and is just suuuuuch a beast of a
>>>>> language
>>>>>>>>> that
>>>>>>>>>>> it would need someone dedicated to its maintenance/evolution.
>>>>>>>>>>>
>>>>>>>>>>> Anywho -- thats what I think about another language in TinkerPop.
>>>>>> I'm
>>>>>>>>> pro
>>>>>>>>>>> SPARQL-Gremlin if it matures and people are excited about it.
>>>>>>>>>>> https://github.com/dkuppitz/sparql-gremlin
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Marko.
>>>>>>>>>>>
>>>>>>>>>>> http://markorodriguez.com
>>>>>>>>>>>
>>>>>>>>>>> On Oct 23, 2015, at 10:45 AM, pieter-gmail <
>>>>> [email protected]
>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Is a opencypher <
>>>>> http://neo4j.com/blog/open-cypher-sql-for-graphs/
>>>>>>>
>>>>>>> ->
>>>>>>>>>>>> gremlin compiler something the tinkerpop team would consider
>>>>>>>>>>> implementing?
>>>>>>>>>>>> Perhaps, hopefully with help from neo4j themselves.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Pieter
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>>
>>
>>
