GraphQL function calls can overwrite eachother

[tub]

If you call the same function more than once in the same (CQL-first) graphql query, one result "wins" and every result for that function call is identical.
This appears to be because the result is a map keyed on the field-name, and since the field-name is the function name, you can effectively only have one result per function.

I've updated the integration tests to cover this case here - tub@e460bdf

It seems like it would need a fairly sizable refactor in order to change how the response is returned to graphql-java, but if anyone has any pointers on how it could be implemented I might be able to find time to do it & submit a patch.

[olim7t]

This is indeed a bug, and I agree with you that the fix is probably not trivial.

The problem with returning generic maps (as we do for rows) is that the GraphQL runtime maps the results using the actual field names, not their aliases in the GraphQL query.

I ran into a similar issue in the schema service. Queries like this one cannot be implemented with maps:

query { keyspace(name:"library") { 
  books: table(name: "books") { columns { name } }
  authors: table(name: "authors") { columns { name } }
}

Because GraphQL looks for a table key in the map for both fields. Even if you manage to put two entries books and authors in the map, they are ignored.

The solution at the time was to turn the map into a DTO, and resolve the field with a method: KeyspaceDto.getTable(DataFetchingEnvironment). Then that method can use its environment argument to figure out more about its invocation context.

This is the same in your example: even though sumPrice and sumSellPrice are different aliases, they designate the same field _decimal_function, hence the collision if we use a map. The problem was hidden until we added aggregations, because regular columns have naturally distinct names.
I think we need to change how we represent rows in response, but it's not as simple as just switching to a DTO, because our field names are still dynamic. I'm going to try a few things locally and I'll report back.

Related:

• Mapping Data in the GraphQL docs
• GraphQL issue on this topic

[olim7t]

I've posted a proof of concept here.