Remove need for search prefix keyword in /query endpoint
Closed this issue · 3 comments
Description
When a user writes a search query for aggregated objects towards Eiffel Intelligence "/query" endpoint they have to prefix the criteria with a keyword representing the aggregated object (or write the actual name of the agreggated object). This is because Eiffel Intelligence handles these queries towards the entire document stored in the database and not the agrgegated object in itself.
I did some digging in the code and found that EI anyway replaces this keyword with the actual name of the aggregated object (both of these properties are set in application.properties btw... The keyword which acts as a placeholder is defined as search.query.prefix, and the name of the aggregated object is defined by aggregated.object.name)
Motivation
It would be preferable to skip the need of the "object" key in the JMESPath expressions. This key is configured in application.properties with "search.query.prefix". When preparing the query EI replaces this key with the actual name of the aggregated object in the database (configured by aggregated.object.name). It is confusing, since this behavior is different from how the conditions in subscriptions are written. In a subscription condition the user writes the condition directly on the aggregated object, and is only interested in getting values from it. I would want the same behavior to apply for when a user makes queries towards the "/query" endpoint to avoid confusion.
Exemplification
How it works today:
User writing a condition for a subscription:
'identity=='pkg:maven/com.mycompany.myproduct/artifact-name@2.1.7'
User writing a query towards the /query endpoint:
{
"criteria": {
"object.identity":"pkg:maven/com.mycompany.myproduct/artifact-name@2.1.7"
}
}
Note that the last example the user has to first specify the keyword for the aggregated object, since the query is done towards the entire document in the database. There is a difference in where you start the JMESPath expression, which is confusing for users. I would prefer if we skip the need of the keyword prefix in the query, so it is consistent syntax in both scenarios. This would mean EI would take care of prefixing the query with the name of the aggregated object, if necessary, or if EI handles the aggregated object directly instead of the entire document when queries come to this endpoint. Perhaps EI should first perform a query to get the aggregated object and then apply the user's query on this data directly?
Benefits
It eases the work for the user if the JMESPath syntax (already a bit complex) can be consistent in every endpoint to EI and it also helps for documentation purposes, as it is easy to re-use examples of JMESPath expressions in several places.
Possible Drawbacks
yes, the query should be same in Subscriptions and query aggregated objects rest entrypoint.
But I guess it works to write object.identity in JmePaths query as well?
I updated the issue, since it is actually the /query endpoint in which this issue occurs :)
Closing this issue since the code changes have been merged.