• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • ehcache
  • vfunshte
  • Reporter: gkeim
  • August 23, 2013
  • 0
  • Watchers: 6
  • February 20, 2014

Description

When crafting a BMQL expression like ‘select key, age, value from Foo’ the special attributes ‘key’ and ‘value’ should be treated like standard, declared searchAttributes WRT results handling. Cache.getSearchAttributes does return the both ‘key’ and ‘value’ but StoreQuery.requestedAttributes does not, and manually adding them results in ‘key not a requested attribute.’

We need this so (1) we can properly insert these columns at the correct location in the result grid and (2) there is consistent results handling. Either that or we need to state that you cannot use these special attributes via BMQL and take them out of the grammer.

There’s a similar issue with aggregates, which reminds me of why we also need support for “column aliasing” via the AS keyword:

select AVE(salary) AS averageSalary

This would result in a single ‘synthetic’ searchAttribute named ‘averageSalary.’

Comments

Gary Keim 2013-08-23

I don’t feel strongly that BMQL should support key & value but I am strongly in support of, if not handling column aliases, at least treating aggregates like regular search attributes in result handling… there should be a search result attribute ‘AVE(salary)’ whose value I can access from the Result like:

int avgSalary = result.getAttribute(“AVE(salary)”);

Fiona OShea 2013-08-26

Please review.

Vitaliy Funshteyn 2013-08-26

I don’t get the issue. {{Cache.getSearchAttributes}} gives you every attribute the cluster knows about at the time of the method call. {{StoreQuery.requestedAttributes}} returns every attribute requested with the search *query*. What’s the problem? If you also need to check if the query asked for keys or values, use StoreQuery.requestsKeys/requestsValues.

Also changes like these are NOT going into Valencia for sure, given that it’s August 26th today. I also already commented on the aggregator aliasing JIRA.