Hello @Harsturomai,

To the best of my knowledge, query complexities are calculated before the queries are performed. If let’s say, in your query, you specify the limit of items to be retrieved to be 10000 and your remaining budget is less than what the cost of retrieving items of that limit is, you will received a Complexity budget error even if the board is empty. Additionally, the level of item properties you retrieve as a huge impact on the Complexity budget. So therefore to avoid falling into complexity budget errors, you have to limit by board, group, number of items etc. You can find more information about this here

As @kolaai said, nesting query options that have implicit high complexity exponentially increases the complexity of the whole request, regardless of how many items are in the board.

So ironically:

• If you query for boards (complexity 1,000) and items (complexity 1,000) nested inside a board, you get a 1,000,000 complexity
  
  Example

query {

  boards {   // <- complexity 1k

    id       //    multiplied by

    items {  // <- complexity 1k

      id

    }

  }

}

• If you query for 10,000 boards and 10,000 items (not nesting the items query) you get a 20,000 complexity
  
  Example

query {

  boards (limit: 10000) { // <- complexity 10k

    id                    //    added to

  }

  items (limit: 10000) {  // <- complexity 10k

    id

    board_id

  }

}

I hope it’s clear how complexity calculation works.

Hi all,

I greatly appreciate your timely responses. It seems like the key factor here is that the cost is pre-computed. Thus, there are these exponential implications irrespective of the actual number of material entities.

I will have to review my query. Also, I gather that this is where pagination can help to retrieve all items but in effective “batches”.

Cheers,

Harry

Yes, I confirm it is.

You better get raw data and build the structure in your app.

@Harsturomai

That’s a great question!

Thanks so much for your input on this @rob and @kolaai, those were super on-point and insightful 🙂 I appreciate you sharing your excellent expertise on this!

@Harsturomai feel free to share the structure of your query with us, and we could try thinking of potential improvements to reduce the complexity cost of your query. We’re here to help!

-Alex

I concede to admit that I am using a dotnet SDK I found on GitHub and was hoping it was plug and play! Seems like I might have to deconstruct it a bit further and write a bespoke query for my use case.

I’ll revisit this in the morning and if I can’t seem to get an appropriate query up and running then I’ll ask back here with more detail.

Cheers,

Harry

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.