microsoftgraph / msgraph-sdk-powershell

Powershell SDK for Microsoft Graph
https://www.powershellgallery.com/packages/Microsoft.Graph
Other
695 stars 168 forks source link

Bulk retrieval of data using the Graph module bundle #265

Closed KirkMunro closed 7 months ago

KirkMunro commented 4 years ago

The Get-Mg* cmdlets in this module bundle seem to handle the "retrieve all" and "retrieve 1" cases pretty well, where you can retrieve all records of a certain type (e.g. Get-MgUser with no parameters) or one record of that type (e.g. Get-MgUser -UserId $userId).

What about retrieve many?

I often need to retrieve a specific set of records, but there isn't an easy way to do that. Most Get-* cmdlets in PowerShell support this by defining the identifying parameter as an array, but in the Graph module bundle, the identifying parameters are singular, so I either need to make many Get-Mg* calls in a row, passing in one identifier at a time, or I need to use the common -Filter parameter with an "or" filter than I manually build.

The first option is undesirable because this requires multiple REST invocations to retrieve what should be a single dataset.

The second option is undesirable because I need to manually build that filter, which is sent as a query parameter to the Graph endpoint, which means I'm limited by the length of the query parameter string and the length of the uri, and I don't want to have to think about such things.

With that in mind, I'm wondering the following:

  1. Is there a better way to retrieve bulk (but not all) data than this using the Graph module bundle today?

  2. Would you consider enhancing the Graph module bundle to make this easier by (a) making identifying properties arrays so that you can look up multiple values at once, and (b) internally using those values to build the minimum required number of calls possible based on management of the query string and knowledge of the max uri string length, eliminating the complexity and knowledge that is otherwise required on the callers part, and making the data retrieval cmdlets scale optimally for automation use?

    Automatic request batching could also play into this, where the bulk request could be broken up into chunks that fit the bounds defined by the request size, and then sent out in one batch request for fast retrieval of the data in Azure, with paged results for the data coming back.

  3. What is the maximum Uri string length that is permitted for a Graph request, and how much of that is available for a query string?

AB#7412

MIchaelMainer commented 4 years ago

Ask for batch support.

KirkMunro commented 4 years ago

@MIchaelMainer Already did, over here: #116. Sounds like you're confirming that batch support is the prescribed way for bulk data when you only want some data back, which is fine.

I think there is still opportunity once batch support is present to absorb that internally, allowing a command such as Get-MgUser to retrieve many users by having the -UserId parameter accept an array and internally using a batched invocation to retrieve those users, so having this tagged as an additional feature request for that makes sense. From a usability perspective, as a scripter I would want to use batch support when I'm invoking something complex, but for simple things the scripting experience should remain simple and absorb the batching work internally within the commands.

sebastienlevert commented 7 months ago

As it's related to Batching and HTTP/2 will solve some of the issues there, I wouldn't invest in this area. The -Filter param does the right job and we're really trying to stay as close as possible to the API behavior. Let's close as not planned.