You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As seen in VESPA-9043 (and numerous other times), it can be unnecessarily expensive (primarily network wise) when the content nodes return the full default summary class (all fields) when only a subset of the fields were requested in the YQL query.
While I understand the technical reason for this, it's not logical to the user that they need to create a separate summary class in addition to specifying this in the YQL select statement. Is it possible for us to add list of fields to be sent down along with query and get an "automatic summary class" returned?
The text was updated successfully, but these errors were encountered:
Implementation note:
We want to do this over RCP only,
so it depends on enabling RPC for summary fetch by default,
which depends on the capability of serializing the query tree over RPC.
Perhaps about a work package amount of work in total, for 2 persons.
I think is not necessary to require that. The path in the backend is the same and no real protocol changes are needed. The summary class sent down is a string. Just send down a comma separated list of fields. The backend can then look up if the strings are a summary class or not.
It is not only the query we need to bring along, at least location and rankproperties etc, are on the side. I would prefer to at least move location inside the querytree where it belongs. insteda of bringing our mistakes with us over in the new protocol.
Also, if you specify ranking.queryCache the query is not needed.
So I would say this one does not have any blockers.
As seen in VESPA-9043 (and numerous other times), it can be unnecessarily expensive (primarily network wise) when the content nodes return the full default summary class (all fields) when only a subset of the fields were requested in the YQL query.
While I understand the technical reason for this, it's not logical to the user that they need to create a separate summary class in addition to specifying this in the YQL select statement. Is it possible for us to add list of fields to be sent down along with query and get an "automatic summary class" returned?
The text was updated successfully, but these errors were encountered: