You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the v2 .NET SDK it contained a Document class that allowed users to access all the system properties like ETag. Should a contract be added in v3 .NET SDK to expose those same properties where the default JSON serializer will deserialize all the system properties?
Pros:
It allows user easy access to the system properties
Users get the new properties automatically on upgrading the SDK
Prevents user errors caused by incorrectly deserializing the responses
Could be expanded to allow easy methods to get partition key and id from the item. This would allow users to only pass the item without needing to explicitly specify the id or pk on item operations.
Cons:
Requires users to take a dependency on the SDK type
Can cause breaking changes in the future if properties are added based on implementation
Not all users will be able to implement or use the provided type
The text was updated successfully, but these errors were encountered:
Hi @j82w is this still being considered?
I'm currently looking for a solution to retrieve _etag and _ts when using GetItemLinqQueryable().ToFeedIterator().
It's still a possibility, but there hasn't been any request for it yet. I think most users have found it easy enough to add the _etag and _ts property to their own objects. We want to make sure that the demand is worth the possible future issues that will come from it.
In the v2 .NET SDK it contained a Document class that allowed users to access all the system properties like ETag. Should a contract be added in v3 .NET SDK to expose those same properties where the default JSON serializer will deserialize all the system properties?
Pros:
Cons:
The text was updated successfully, but these errors were encountered: