Please help - can't get column_values?

Hello there @geeemaaan,

You can use something like this:

{
  items(ids: [1234567890]) {
    name
    id
    column_values {
      id
      value
      text
      column {
        id
        title
      }
    }
  }
}

If you want to get the items inside of a board, you can use items_page as explained here.

Cheers,
Matias

hi @geeemaaan

In the new API items as a subset of boards is replaced by items_page, see Items. If you only want to get the column values for a given item the example you have here is very complex and costly. Why not just:

items (ids: [‘id_here’]) {
  name
  id
  column_values {
    id
    title
    value
    text
  }
}

Also note that text will return null for all mirror, dependency and a few other columns. See also fragments at Column values v2

Thanks so much for the reply. This got me on the right track.

It’s weird that ‘id’ is available to ‘column_values’ and ‘column’ , yet ‘title’ is only available to column.

Hi Bas, your example code caused a syntax error. ‘title’ is only available to ‘column’ , not ‘column_values’ (like it used to be) … Matias’ example shows a working syntax.

My overly-complicated query was a result of reading the Monday docs which state that it’s quicker to narrow search by board, rather than at the root item level. But the docs (or my reading of them) might be wrong.

hi @geeemaaan

Correct, I did not include the column id and title. If you want to do this from the board level (faster?) you can still do that by using the items_page object. Like:

{
  boards(ids: THE_BOARD_ID) {
  items_page (ids: [THE_ITEM_ID] {
    cursor    
    name
    id
    column_values {
      id
      value
      text
      column {
        id
        title
      }
    }
  }
  }
}

These answers are just to help you figuring out. All information in available at The basics

Thanks Bas, I appreciate it. Sometimes reading the docs can be really painful (especially just after new year!) …whereas a code example can turn on the lightbulb quickly. Hopefully this thread will help someone else too.

Who knows if the query is faster from the board level ( @Matias.Monday ) ???
In reality for my application it’s probably not too important.

I don’t work for monday.com so the below is based on my understanding of how GraphQL APIs would work in general and my experience with the monday.com API.

When it says nesting “items” in “boards” is “faster” its a little misleading.

A root query of items, boards, users, updates, whatevers has an intrinsic limit of 100 objects.

If you have 1000 item IDs, in the past you could fetch them all in one request by nesting items within the board. The items within board had a limit of 1000. In 2023-10, items_page is now required and has a limit of 500 - it also works differently.

EDIT: it has been brought to my attention that even the items within boards is limited to 100 item Ids. So that isn’t even faster.

It is this ability to fetch more items in a single request which made it “faster” - if you have more than 100 Ids to fetch in the past.

board.items_page.items with an array of a few item IDs is actually SLOWER than using items at the root. This is because the API resolver would first resolve the board, then use items_page to resolve a list of items (gets all item id then filters by the ids provided), then the items resolver to resolve the items themselves.

Using items at the root, with IDs uses the items resolver directly to resolve that list of IDs - esp. if it is less than 100 IDs. But even if you did have more you could execute two parallel requests for say 100 items (200 total) and it would still be faster than using boards for you.

Additionally if using items_page and you don’t specify a limit equal to the number of Ids provided, the API complexity goes WAY up because it processes as though its retrieving 500 items even though you’re only fetching 10. This is because the item_ids parameter of items_page is a filter of items fetched, not a request for specific item IDs.