If you're performing a GraphQL query for content fragments, under the hood our experience is that it creates a SQL2 query performed against a special index (dam:IndexedFragmentData) taht I believe is suited to this purpose. This is an example of what we see under /libs/granite/operations/content/dia...

I can't speak for @krati_garg or @ravir73578276 , but eventually what helped us was to take the SQL2 query generated under the hood by AEM and work with that. You can find recent or slow GraphQL queries under /libs/granite/operations/content/diagnosistools/queryPerformance.html. You'll notice them b...

That worked. Thank you. What a helpful post overall.

Thanks for answering. Do you know how to set this in a local environment using the Cloud SDK? Is it the same procedure as On Prem? 

I know this is old, but in case you're still monitoring this thread I'm curious how you determined under what circumstances your GraphQL query would generate one SQL2 query under the hood vs. the other. We are experiencing a strange situation where some environments when performing a GraphQL query s...

I'm still wondering about this.  Anything, @krati_garg ?

Recently I encountered a project with a complex model package structure and looked into how best to support this. I found documentation at WCM.io that indicated this.  <!-- Export all non-internal packages by default --> Export-Package: !*.impl.*,!*.internal.*,\ io.wcm.samples.*Replace io.wcm.sample...

Thanks for this. We dealt with AEMaaCS support and they didn't even recognize this issue, so it's a relief to see someone recognize it. 

I saw that as well. I'm curious what its function is, though. 

Regrettably this seems to be a bug with a particular version of GraphQL in the environments. The team at AEM Cloud Services rolled back to an older version of the environment and the GraphQL query began working again. I would love to know what the underlying cause is, though.