@qqq non-indexed queries are considered a bug in datastore. No scanning allowed.
And they changed their read costs so projection queries aren’t cheaper. They may be faster though.
(you will find the space allocated to indexes are often ~10x the space of your data itself)
I prefer my DSL in cljgae-template
:
(query-<Noun> [:and [:someprop > 5] [::someprop <= 17]])
over
… {{:age #(> % 27)} {:name “Smith”}}
But reasonable people can disagree.nickbauman: what's <Noun> mean?
these [...] things are macros?
fwiw, i like the simplicity and transparency of treating maps as AND clauses and sets of maps as OR clauses. ie not
… {{:age #(> % 27)} {:name "Smith"}}
but … {:age #(> % 27) :name "Smith"}
vs. ... #{{:age #(> % 27)} {:name "Smith"}}
Noun is the entity you declared in the first place
(defentity Dog [:property-a :property-b :property-c])
(query-Dog [:and [:property-a < 4] [:property-b > 5]])
Also:
(query-Dog [:or [:property-a < 4] [:property-b > 5]])
where does "query-Dog" come from?
side-effect of (defentity Dog ...)?
Correct. The defentity macro creates the functions.
You don't have to use those functions, mind you. You can create a symbol and plink that into the query function on your own. At some point I’m going to tease this out so you can use it however you want it. So that you can even do kindless queries if you want.
i wonder if you could make it more clojurish by mimicking defrecord. e.g. #Dog.query[...] and vector-?Dog[...] or some such. see https://clojure.org/reference/datatypes
"query-Dog" seems a little too magical to me, fwiw.
i rather like #Dog.query[...].
Yeah. Pros and cons. The fellas over at SIFT tell me when they have a problem they just write the solution in text in an imaginary language that seems best suited for they problem. Then they implement the language using Lisp. They’ve written hundreds of DSLs. http://www.sift.net/
FWIW I value readability over all other things. One of the last things I value is syntax. And then it’s ALWAYS the less syntax the better.
i'm also a fanatic about readability, but i tend to think more in terms of expressivity. expressivity being a property of languages, whereas readability is a property of texts.
to me syntax is absolutely central, because expressivity follows from it. it's more important than vocab, since you can have a great vocab with indecipherable syntax, but not vice-versa.
Readability is almost always the opposite of expressivity.
Ruby is all about expressivity
Python is all about readability
howso? perl is very expressive. it's also very readable, to an expert fluent in the language. of course one can write unreadable texts in any language, no matter how expressive. but that's a writing problem for which the author rather than the language is responsible. that's why i think expressivity is central to language design. the designer has control over that, but no control at all over the readability of things people write.
the expressivity of clojure is one of it's main attractions. ironically, noobs often complain that all the parens make it unreadable.
Expressiveness is often a proxy for terseness. You get this with weird sigils in perl, for example.
The terseness often leads to side-effecty / magic behavior.
Magic behavior, by definition, isn’t readable.
I love this explanation of the balance of syntax and semantics of Lisp: https://news.ycombinator.com/item?id=13008649
Also cljgae-template
query DSL returns a lazy sequence on a cursor, which means you can materialize only what you need only when you need it.