clojurewerkz.elastisch.native.document/search, _source question (and maybe a couple more)

Skip to first unread message

Dave Tenny

Jun 1, 2016, 7:34:25 PM6/1/16
to clojure-elasticsearch
I'm using the master version of Elastisch with ES 2.3.  

Why is it that most of the search keywords are as documented for Request Body Search
except that source filters requires :_source instead of :source?

Also, if you specify :_source [ <fieldnames> ] the field names must be strings instead of keywords (keywords will fail).
whereas there are some other APIs I've used in Elastisch that favor keywords instead (and fail with strings, sorry, I don't remember which API that was).

Is it a goal that the API, when referring to field names, type names, index names, and so on, should allow both strings and keywords? 

Dave Tenny

Jun 1, 2016, 8:05:59 PM6/1/16
to clojure-elasticsearch
I guess I see where _source is coming from, matching the result of the search.  
Only as I formulate the set of options for the search, I'm following the elasticsearch documentation on the search options, thus the impedance mismatch.
So I suppose it's a matter of taste, but if it was consistently named the ES documentation (or better documented in the search docstring), then it would have saved a failed program run.

What do you think about the practice of providing documentation and keyword declarations for all Elastisch supported SearchRequest options
(in clojurewerkz.elastisch.native.conversion/->search-request) in the 
clojurewerkz.elastisch.native.document/search function docstring, so that they're available when people are coding search calls?

[If only clojure had an option to enforce keyword parameters vs. actual arguments at compile time that would benefit hoisting keywords even further, but generic map destructuring
doesn't provide that].

Just curious.  You can tell I have documentation intensive leanings.  I'm just wondering whether trivial pull requests along those
lines might welcome.
Reply all
Reply to author
0 new messages