Possible Bug in cbElasticsearch

Communities ColdBox HMVC
1

Hi,

I’ve been digging deep into cbElasticsearch for my project and I think I may have uncovered a bug, but not quite sure how to fix it. The bug is related to using the Query DSL language and constructing a query.

In the SearchBuilder.cfc when the new() method is called to build up the search string it loops through the property names. Everything works fine until you add the property “startRow” then it breaks for some reason and the query string that gets passed to the execute method doesn’t work.

Looking at the code it appears fine. As an example here is my code:

This code works fine if you remove the “startRow” key, but adding it seems to throw off how the query json ends up being built. I am trying to use the startRow so I can leverage paging in my application ultimately.

var searchResults = getInstance( “SearchBuilder@cbElasticSearch” )
.new(
index = “jobs”,
type = “_doc”,
properties = {
“query” = {
“term” = {
“active” = true
}
},
“startRow”: 10,
“maxRows” : 30,
“sort” : [{“date_posted” : {“order” : “desc”}}]
}
);

2

Hi

This is a bug in the SearchBuilder.

See https://github.com/coldbox-modules/cbox-elasticsearch/pull/53

------ Originalnachricht ------

3

Thanks, I see what you added to fix it, I guess I just missed that thinking it was something more complex.

Not directly related, I do wonder why the code uses “startRow” and “maxRows” rather than what Elasticsearch uses which is “from” and “size”. It seems that it would be nice to be consistent, but who am I to complain really as I’m happy that someone took the time to put the module together to say the least.

4

Jon probably used the usual CF parameters as with cfquery.
I personally would prefer the elasticsearch syntax as well and have stumbled upon it several times.

You can make a pull request with two additional aliases (from/size) pointing to the internal maxrows and startrow.

------ Originalnachricht ------

5

I can implement the aliases. We have a release bump forthcoming, anyway.

Andreas is correct, though. A low barrier of entry for CFML devs was the reason for those naming conventions.