-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better way to match BatchResult with request #1374
Comments
@wizofaus : As the various 'batch' methods return different types (adding a list item returns an IListItem, deleting an item returns nothing) there's no way for you capture the id of the created internal What information in |
Just some way of matching reach Batch result with the corresponding batched request so I can tell which ones have failed.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Bert Jansen ***@***.***>
Sent: Tuesday, February 13, 2024 8:02:11 PM
To: pnp/pnpcore ***@***.***>
Cc: wizofaus ***@***.***>; Mention ***@***.***>
Subject: Re: [pnp/pnpcore] Better way to match BatchResult with request (Issue #1374)
@wizofaus<https://github.com/wizofaus> : BatchRequest is for the most part an internal class, only few properties are exposed to enable custom API calling to use batching. The BatchResult class returns all the information needed to understand the failed request and that information is copied from the starting BatchRequest.
As the various 'batch' methods return different types (adding a list item returns an IListItem, deleting an item returns nothing) there's no way for you capture the id of the created internal BatchRequest, therefore making it hard to later on link back to the BatchRequest.
What information in BatchRequest do you feel is missing for being able to realize your scenario?
—
Reply to this email directly, view it on GitHub<#1374 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABI5UAKP4N6TGRNSZWXZYY3YTMTZHAVCNFSM6AAAAABCWD3INSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBQHAZDCMBWHA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
@wizofaus : What I can do is make the Id of the var batch = context.NewBatch();
// Sample on how to track additional information for a batch request
Dictionary<Guid, int> deletedListItemIds = new();
for (int i = 1; i <= 150; i++)
{
await myList.Items.DeleteByIdBatchAsync(batch, i);
deletedListItemIds.Add(batch.Requests.Last().Value.Id, i);
}
// Execute the batch without throwing an error, should get a result collection back
var batchResponse = await context.ExecuteAsync(batch, false);
// Find the corresponding batch requests
foreach (var errorResult in errorResults)
{
var failedListItemIdDelete = deletedListItemIds.FirstOrDefault(p=> p.Key == errorResult.BatchRequestId).Value;
} |
…ding `BatchResponse` to enable more advanced batch handling scenarios #1374
@wizofaus : just pushed the change that enables this. Closing this issue now |
I can see this Id is public now, but just to confirm, I have to rely on knowing the order of the request in the current batch to match them with my input data? (i.e. I can't just associate my own data with each request). And I note that BatchResult constructor is still internal, but I need to call it for mocking purposes. Which is only possible currently via reflection - which of course caused errors on running those tests now that you've added a new parameter! |
Category
Describe the feature
Would like the ability to reliably/safely determine which BatchResult (as returned by IPnPContext.ExecuteQuery) matches with the corresponding BatchRequest.
Describe the solution you'd like
Something like
Alternatively I'd be quite happy if
RecycleByIdBatchAsync
(and similar functions) returned back a BatchRequest object from which the BatchResult info was available explicitly after calling ExecuteAsync( ):Additional context
Currently have to do it by assuming that the BatchResult.ApiRequest string happens to match a particular pattern (e.g.
/items(<id>)/recycle
in this case).The text was updated successfully, but these errors were encountered: