search

edn-query-language / eql

EQL is a declarative way to make hierarchical (and possibly nested) selections of information about data requirements. This repository contains the base specs and definitions for EQL parsing, AST, etc.
http://edn-query-language.org
MIT License
381 stars 18 forks source link

Support for string keys? #19

Open kennyjwilli opened 2 years ago

kennyjwilli commented 2 years ago

The EQL specification defines properties as "Clojure keywords; they can be simple or qualified keywords, and they express the property been requested." When only working with Clojure data, this definition makes sense. There could be cases where external data is given as a JSON document where keywordizing keys is not preferable (i.e., certain keys are not valid keywords), yet the EQL format still has merit.

What are the authors' thoughts on adding support for string properties? For example, the below query would be valid. 

;; Query 
["a" {"b" ["c"]}]

;; AST 
(query->ast ["a" {"b" ["c"]}])
=>
{:type :root,
 :children [{:type :prop, :dispatch-key "a", :key "a"}
            {:type :join,
             :dispatch-key "b",
             :key "b",
             :query ["c"],
             :children [{:type :prop, :dispatch-key "c", :key "c"}]}]}
awkay commented 2 years ago

My take would be "convert the JSON request to clj data, then process those strings into keywords". That way you don't lose namespacing, which is also important: ["a/b"] -> [:a/b]. IMO it is an external concern that is fixable with a simple wrapper and should not be a concern of EQL itself.