Roadmap 2019, in which position is support for other QLs?

(giovanni tummarello) #1

Hi

i know that you guys are familiar with your query language and questions about supporting others can be irritating :slight_smile: i know.

However it is a fact that people do not feel like learning other languages, and at the same time there is an issue of perceived safety when a DB claims to be supporting a “known” language.
Also it might be me but i find GraphQL+ pretty difficult to even understand for questions other than trivial entity lookups

It might be me but… :slight_smile: anyway. here is the question are languages like https://www.opencypher.org/ (better) or Gremlin realistically planned for 2019 and if so is there a ETA?

I get a great feeling from the dgraph technology but its hard to imagine using it without the"cozy feeling" that it supports languages which have been used successfully by others.

Thanks and have a great end of the year.

(Michel Conrado (Support Engineer)) #2

About the opencypher and Gremlin see last update about it https://github.com/dgraph-io/dgraph/issues/1966

(giovanni tummarello) #3

Bad idea IMO, but you guys must have your reasons. For me it makes it very difficult to consider as opposed to others which have either a standard syntax (cypher, gremlin or sparql) or a much more simple one (arangoDB and others)

(Johannes BrĂĽderl) #4

i personally enjoy dgraph’s syntax. it’s more “webby”, and brings some fresh air to the graph database landscape. real graphql compliance is the right direction, IMHO :slight_smile:

(Manish R Jain) #5

I think on a general level, the priority goes like this:

  • Official GraphQL spec.
  • Gremlin.
  • Cypher? / GQL? / SPARQL? – we’ll have to decide based on the adoption. Cypher, while popular, is still a niche language, and not a standard by any means. Neo4j is pushing for GQL, so by the time we support Gremlin, hopefully it is clear where do these cards fall. https://gql.today/