Building a queries about elasticsearch-rails

[karmi]

Agreed that JBuilder is far from ideal for building large queries, though it works nicely for simple stuff.

The approach you outline is definitely valid, and allows you to define the builder in the context of your application, which is definitely a good thing.

Two notes:

• Have a look at https://gist.github.com/msonnabaum/b3950b42e5d9d8b37c2a#file-es-query-rb where Mark is using an "immediately called lambda" pattern to be able to execute custom logic in a Hash definition.
• I definitely plan to have an elasticsearch-dsl gem, which would expose a DSL for defining the search requests expressively in Ruby. I haven't yet started on it, though, since there are more pressing priorities, such as a "persistence" module for elasticsearch-model.

[karmi]

@gzigzigzeo Closing this, if you don't mind. Please reopen, ping me, or open another issue if you want to discuss it more.

[gzigzigzeo]

Thanks for your answer! Sorry, I did not saw the reply notification. Finally, I came to other way of sanitizing queries:

      query = {
        fields: [:_timestamp, :_source],
        sort: { _timestamp: :desc },
        size: 0,
        query: {
          filtered: {
            filter: {
              and: [
                { term: { lookup_status: options[:lookup_status] } },
                { term: { advert_import_id: options[:advert_import_id] } }
              ]
            }
          }
        },
        aggs: {
          queries: {
            terms: { field: :addressing_query_id, size: 200 }
          }
        }
      }

      Elastic::QuerySanitizer.sanitize(query) # Removes empty nodes

Sanitizer does exactly the same job, but it works post-factum. So, query stays regular hash during the building & execution which is much simplier than DSL especially for complicated queries because large query could be split into smaller chunks without any tricks.

[karmi]

Yeah, that can work as well. I must admit I really become to enjoy the "immediately called lambda" pattern I linked above. See eg. an example application here: https://github.com/elasticsearch/elasticsearch-rails/blob/persistence/elasticsearch-persistence/examples/sinatra/application.rb#L96-L112

Once we have the elasticsearch-dsl gem, this all should be much more convenient.

[gzigzigzeo]

Yep, saw it, but 1) this pattern looks much more dirty than just a plain hash. Expressions like "if t && !t.empty?" are okay until you have 2-3 terms or you do not have nested filters. 2) I am sorry, but did not understand what's the advantage of using inplace lambda vs use of instance method returning hash (def query(q, t))?

With sanitization even large queries stays readable: https://gist.github.com/gzigzigzeo/10825032 The only one bad thing about sanitization is that it should know about DSL keywords in some cases :(

[karmi]

There's no problem with a regular def query(q, t) ... method, of course. I linked the example only to show how it can be done without any "query builder" object.

[gzigzigzeo]

Ah, yes, now I understood. But unfortunately, overhead on conditions takes more lines of code than the query itself. So, we're waiting for a elasticsearch-dsl gem :) Thank you.