-
Notifications
You must be signed in to change notification settings - Fork 31
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
Delta
functions should have Deltatoken
query parameter
#354
Comments
Can we add a XLT transform to fix it? All /delta endpoints should support deltaLink. |
OpenAPI.Net.Odata should use the ChangeTracking annotation to know if the query parameter is required. This should be transfer to that repo. |
Isn't the |
According to the link below, it looks like the However, the delta functions currently do not seem to have this in the annotations, but current To me it looks like, we may either have to add the ChangeTracking annotation to the delta functions then modify the lib to pick them up or simply add the Thoughts? cc @darrelmiller, @irvinesunday |
We have to be careful in what we consider here. With that being said the guidance to Graph users has always been "odata next and delta links are opaque, don't try to parse them, use them as it". That's because in a lot of cases re-building the complete URL correctly is error prone. We often see situations where the client passes the delta/skip token + a bunch of query parameters that are already encoded in the token itself, messing things up. This is why those two query parameters are not being projected by the conversion library. This is also why we're not exposing those query parameters as parameters/properties in the SDKs. |
I was the one testing PowerShell when encountered this scenario, which is the following: When calling delta endpoint in PowerShell, the SDK handles all the calls to get the response: microsoftgraph/msgraph-sdk-powershell#1908. So, when there is more than 1 page, PowerShell uses the Hope this clarifies @baywet |
Thanks for the clarification. |
I would assume that we would call something like: Get-MgUserDelta -DeltaToken $token Even our code snippets generation logic assumes the same 😆 as what you are calling would be: I guess this is why the first ask from @peombwa was to get the deltaToken. |
I'm asserting that the cmdlet should instead be Get-MgUserDelta -DeltaLink $link # value from the odata.deltalink property of the previous call And that our snippets should be updated accordingly to reflect our recommendation. |
Sorry I missed the previous discussions. The original request of exposing Is using the |
yeah it's possible in kiota although a bit cumbersome you effectively need to do something like this var requestBuilder = new UsersDeltaRequestBuilder("deltaLink", client.RequestAdapter);
var firstPage = await requestBuilder.GetAsync(); we're looking into ways to make that simpler. |
Perfect! We'll track the feature request at microsoftgraph/msgraph-sdk-powershell#2062 (comment) for PowerShell SDK v3. @irvinesunday, feel free to close the issue as the feature will need to be handled by the SDKs. |
We need to update the code snippet logic for those already using Kiota versions. |
Couple of additions in that space SharePoint/OneDrive is the only service to have an additional function definition with the token, this creates unnecessary overrides and the second one with the token should be removed. <Function Name="delta" IsBound="true">
<Parameter Name="bindingParameter" Type="graph.driveItem" />
<ReturnType Type="Collection(graph.driveItem)" />
</Function>
<Function Name="delta" IsBound="true">
<Parameter Name="bindingParameter" Type="graph.driveItem" />
<Parameter Name="token" Type="Edm.String" Unicode="false" />
<ReturnType Type="Collection(graph.driveItem)" />
</Function> We're working to improve access to the request builder with an arbitrary url microsoft/kiota#3199 |
I believe the second function creates a function with a path parameter argument as opposed to a query parameter argument. Removing it would block scenario 3 and 4 where the specific API allows using timestamps or retrieving the current token which are client-side driven scenarios. In this situation, I think the right thing to do is that the docs examples should probably be fixed so that the examples using the query parameters are replaced with examples using path parameters as much as both do work.
|
ah good call! I forgot the ODSP delta implementation was not conform with the rest of the API surface 🤦♂️ |
All
Delta
functions should haveDeltatoken
query parameter viaCustomQueryOptions
as described in the API reference at https://learn.microsoft.com/en-us/graph/delta-query-users?tabs=http#deltalink-request.Deltatoken
is used to get to pass thedeltaToken
from the last response, you'll get changes (additions, deletions, or updates) to resource since the last request.OData capability annotations allows for:
The text was updated successfully, but these errors were encountered: