Skip to content
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

The implementation and default behavior of UpsertEntity differs in C++ compared to other languages #6230

Open
ahsonkhan opened this issue Nov 15, 2024 · 2 comments
Assignees
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Tables

Comments

@ahsonkhan
Copy link
Member

  1. The default value of UpsertEntityOptions is UpsertKind::Update in C++, but it is Merge in other languages.
  2. We are calling AddEntity in the exception path for some reason, which the other language SDKs don't do. Why do we do this?

C++ implementation:

Azure::Response<Models::UpsertEntityResult> TableClient::UpsertEntity(
Models::TableEntity const& tableEntity,
Models::UpsertEntityOptions const& options,
Core::Context const& context)
{
(void)options;
try
{
switch (options.UpsertType)
{
case Models::UpsertKind::Merge: {
auto response = MergeEntity(tableEntity, Models::MergeEntityOptions(options), context);
return Azure::Response<Models::UpsertEntityResult>(
Models::UpsertEntityResult(response.Value), std::move(response.RawResponse));
}
default: {
auto response = UpdateEntity(tableEntity, Models::UpdateEntityOptions(options), context);
return Azure::Response<Models::UpsertEntityResult>(
Models::UpsertEntityResult(response.Value), std::move(response.RawResponse));
}
}
}
catch (const Azure::Core::RequestFailedException&)
{
auto response = AddEntity(tableEntity, Models::AddEntityOptions(options), context);
return Azure::Response<Models::UpsertEntityResult>(
Models::UpsertEntityResult(response.Value), std::move(response.RawResponse));
}
}

P.S. The (void)options line should be removed (on line 604), since the options are being used here.

.NET implementation:
https://github.com/Azure/azure-sdk-for-net/blob/4e1173308d32f0413788359a87376e673f2ab15b/sdk/tables/Azure.Data.Tables/src/TableClient.cs#L818-L856

GoLang implementation:
https://github.com/Azure/azure-sdk-for-go/blob/3ebd0d439f9d8aa06a0764a60892a8001b997a34/sdk/data/aztables/client.go#L420-L478

cc @jhendrixMSFT, @christothes

@ahsonkhan ahsonkhan added bug This issue requires a change to an existing behavior in the product in order to be resolved. Tables labels Nov 15, 2024
@gearama
Copy link
Member

gearama commented Nov 15, 2024

works as expected

@gearama gearama closed this as completed Nov 15, 2024
@ahsonkhan
Copy link
Member Author

There's a behavioral difference, and our SDKs need to be:

  1. Idiomatic to the language.
  2. Consistent across languages where (1) isn't lost.

That's written in our design guidelines:
https://azure.github.io/azure-sdk/cpp_introduction.html#cpp-principles

Client libraries should be consistent within the language, consistent with the service and consistent between all target languages. In cases of conflict, consistency within the language is the highest priority and consistency between all target languages is the lowest priority.

@gearama gearama reopened this Nov 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Tables
Projects
None yet
Development

No branches or pull requests

2 participants