Skip to content

Preload dates_source when the widget is requested

What does this MR do and why?

Whenever the/epics page on the group level is loaded (and not only, every time we are requesting the widget WorkItemWidgetStartAndDueDate on a query to get the WorkItem), some n+1 queries are executed for loading the dates_source relations, as they are loaded for each work item. In this MR, we are trying to preload the associations for all the work items to avoid the extra queries to the DB.

As you can see in the before screenshot, for each work item, we are loading the dates_source table. In the after screenshot, we are preloading the records and we are performing only one query to load them all.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After
Screenshot_2024-09-30_at_15.33.59 Screenshot_2024-09-30_at_15.34.29

How to set up and validate locally

A simple way to validate it, it to go in graphiql explorer in your local environment and perform this sample query, and check your logs for WorkItems::DatesSource Load.

graphql query
query getWorkItems($fullPath: ID!) {
  group(fullPath: $fullPath) {
    id
    workItems(
      includeDescendants: true
    ) {
      nodes {
        id
        widgets {
          type
          ...WorkItemWidgets
        }
        workItemType {
          name
        }
      }
    }
  }
}

fragment WorkItemWidgets on WorkItemWidget {
  ... on WorkItemWidgetStartAndDueDate {
    type
    dueDate
    startDate
    rollUp
    __typename
  }
}


# Variables 
# {
#  "fullPath": "The ID of your group"
# }

Edited by Stefanos Xanthopoulos

Merge request reports

Loading