Comments (9)
Hi @ashmrtn,
Thanks for using the Go SDK and for reaching out.
This is intentional so people can reset values on APIs (a commonly used pattern).
The serialization infrastructure should only be sending nulls when:
- the object has been previously obtained from the API.
- a property has explicitly been set to nil by the application.
- the object is being sent back to the API.
Which seems to match your case to some extent.
Can you share a snippet of code of how the copy is done today in your application?
from kiota-abstractions-go.
We're using the graph SDK in an open source project called Corso which is meant to backup and restore M365 data for users. Our end goal with the bit of code we're working with is to get an object model that we can send to microsoft to create a new version of the object with a distinct ID from the original object. In the example, fields we're clearing are ones that will either cause server issues (found through experimentation) or are ignored by the server and don't need to be sent (except maybe the odata type, though that was never an error before)
Right now we're doing the copy by manually selecting the fields (some of which need cleared, others of which are just pulled from the original). I was sort of hoping to switch this copy to something better in the future by maybe using reflection to avoid having to pick and choose which fields are copied over as that seems error prone if the API expands. Doing a manual copy requires intimate knowledge of the API, how it evolves over time, and which fields are important and need selected
from kiota-abstractions-go.
Thanks for the additional context here. This is a bit of a specific scenario compared with the typical usage.
For the properties you want to reset without sending null to the API, you could do something like that.
myModel.GetBackingStore().SetInitializationCompleted(false);
myModel.SetProperty(nil);
myModel.GetBackingStore().SetInitializationCompleted(true);
Let us know if you need anything else.
from kiota-abstractions-go.
is this going to be the only way to handle this going forward? I'm a little concerned that it's going to make it difficult to write correct code since it requires special handling of some fields and it's not necessarily clear when special handling should be used and when it shouldn't. As there's no written documentation for how to handle this or why it needs to be handled that way, correctness would rely on the code author and/or the code reviewer having the tribal knowledge that that's the proper way to do things
If my understanding of the various SDK libraries and HTTP CRUD operations is correct, the recent update to this library would mostly be applicable to PATCH requests right? I could see some cases where needing to set a field to null
could be important to clear a default value when creating a new object (POST), but it seems far more likely to be used during item updates (PATCH)
from kiota-abstractions-go.
Yes this is the main scenario we've designed this for:
- GET an object.
- Reset a property by setting it to null.
- PUT or PATCH the object back to the service to reset the property there.
Although this is discouraged by REST guidelines, nothing prevents an API provider from using post for update purposes. This is especially true when the update requires additional ephemeral parameters. For example an update meeting endpoint that would take the meeting + a couple of parameters like "send update email notification" etc.
Finally, the serialization infrastructure doesn't have knowledge of what http method is in use, those are orthogonal.
Because these accessors are exposed by the Backed model interface, you should be able to come up with a generic solution that can be applied to all models types.
The alternative being to generate your own Microsoft graph client using kiota, without the baking store if you want.
from kiota-abstractions-go.
I've been working on updating the code my team maintains using the workaround you suggested. However, I'm a bit confused as to when I need to use the workaround you suggested and when I don't. For example, should I only be using it if setting a field to nil? Is there some form of documentation explaining that information?
from kiota-abstractions-go.
Thanks for the prompt, I have created an issue in our documentation repository
I'd say you'd need to implement the workaround (assuming we're talking about switching the flags for the backing store and not generating your own client without the backing store) any time you:
- get an object from the API.
- set one of it's properties to null.
- send the object back to the API BUT you don't want that property to be sent as null on the payload.
Hopefully that clarifies the scope.
from kiota-abstractions-go.
yes, that info is super helpful! You're right that I was talking about switching the flags for the backing store and sorry for not clarifying that initially
Thanks for also creating an issue for adding documentation around this. It'll be good to be able to point other engineers on my team to it if/when needed
from kiota-abstractions-go.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.
from kiota-abstractions-go.
Related Issues (11)
- Clarification on ParseNode Usage HOT 4
- The factory type should be corrected HOT 1
- Updating a slice or a map from the in-memory backing store results in a panic HOT 2
- concurrent map writes in github.com/microsoft/kiota-abstractions-go/api_client_builder.go:70 HOT 7
- fatal error: concurrent map read and map write HOT 6
- swap uri template for std uri template
- Exploded query parameters are not working HOT 2
- strip https:// prefix if present in allowed host value
- remove string empty test when adding query parameters
- Guid uri template path/query parameter values should be normalized to string
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kiota-abstractions-go.