Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

PathQuery looks a lot like GROQ [1], which is the query language used by the Sanity data store [2]. For example, one of the queries in the paper:

  @entities
    .[/type == (Id(/ museum ) , Id(/ theme_park ))]
    .{
      id: ?cur
      require name: /name.[TextLang() == en ]
      @merge : events::GetInfo()
    }
can be written something like:

  *[type == "museum" || type == "theme_park"] {
    id,
    name: select(name[lang == "en"] => name),
    ...{
      // GROQ doesn't have functions, so GetInfo()
      // would need to be inlined here
    }
  }
PathQuery is of course a lot more complex, but the basic structure seems very similar. One thing GROQ does not have yet is recursive querying of the type needed to traverse graphs, but this is on our roadmap to implement.

We've published a public draft specification for GROQ, and hoping it will be adopted by more tools. For example, we already have an open-source JavaScript implementation of it.

(Disclosure: I work on GROQ at Sanity.)

[1] https://github.com/sanity-io/GROQ

[2] https://www.sanity.io/



It seems PathQuery's entire novelty is better handling of recursive querying for query optimization, but "details are admittedly not discussed herein".

So the paper has a sort of weird feel. It goes like this: PathQuery is a good language, because it has good semantics and it is optimizable. Some words on its good semantics. We don't discuss how it is optimizable, but trust us, it is.


From what I can tell, PathQuery is also clever in how queries express the shape of the returned data, which we in GROQ call projection. For example, in GROQ you can do:

  *[type == "user"] {
    id, name,
    "slug": id + "-" + lower(name),
    "photos": photos[] {
      url, width, height
    } | order(position),
    "newestComment": *[_type == "comment" && author == ^.id] | order(createdAt desc)[0] {
      id, body
    }
  }
PathQuery seems to give you similar tools in transforming data as part of your pipeline, which I think is how query languages should be like.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: