/// <summary>
/// Creates, updates, or removes resources. This method supports atomic
/// transactions with multiple types of resources. For example, you can
/// atomically create a campaign and a campaign budget, or perform up to
/// thousands of mutates atomically.
///
/// This method is essentially a wrapper around a series of mutate methods. The
/// only features it offers over calling those methods directly are:
///
/// - Atomic transactions
/// - Temp resource names (described below)
/// - Somewhat reduced latency over making a series of mutate calls
///
/// Note: Only resources that support atomic transactions are included, so this
/// method can't replace all calls to individual services.
///
/// ## Atomic Transaction Benefits
///
/// Atomicity makes error handling much easier. If you're making a series of
/// changes and one fails, it can leave your account in an inconsistent state.
/// With atomicity, you either reach the desired state directly, or the request
/// fails and you can retry.
///
/// ## Temp Resource Names
///
/// Temp resource names are a special type of resource name used to create a
/// resource and reference that resource in the same request. For example, if a
/// campaign budget is created with `resource_name` equal to
/// `customers/123/campaignBudgets/-1`, that resource name can be reused in
/// the `Campaign.budget` field in the same request. That way, the two
/// resources are created and linked atomically.
///
/// To create a temp resource name, put a negative number in the part of the
/// name that the server would normally allocate.
///
/// Note:
///
/// - Resources must be created with a temp name before the name can be reused.
/// For example, the previous CampaignBudget+Campaign example would fail if
/// the mutate order was reversed.
/// - Temp names are not remembered across requests.
/// - There's no limit to the number of temp names in a request.
/// - Each temp name must use a unique negative number, even if the resource
/// types differ.
///
/// ## Latency
///
/// It's important to group mutates by resource type or the request may time
/// out and fail. Latency is roughly equal to a series of calls to individual
/// mutate methods, where each change in resource type is a new call. For
/// example, mutating 10 campaigns then 10 ad groups is like 2 calls, while
/// mutating 1 campaign, 1 ad group, 1 campaign, 1 ad group is like 4 calls.
/// </summary>
/// <param name="request">The request to send to the server.</param>
/// <param name="headers">The initial metadata to send with the call. This parameter is optional.</param>
/// <param name="deadline">An optional deadline for the call. The call will be cancelled if deadline is hit.</param>
/// <param name="cancellationToken">An optional token for canceling the call.</param>
/// <returns>The call object.</returns>
public virtual grpc::AsyncUnaryCall <global::Google.Ads.GoogleAds.V6.Services.MutateGoogleAdsResponse> MutateAsync(global::Google.Ads.GoogleAds.V6.Services.MutateGoogleAdsRequest request, grpc::Metadata headers = null, global::System.DateTime?deadline = null, global::System.Threading.CancellationToken cancellationToken = default(global::System.Threading.CancellationToken))
{
return(MutateAsync(request, new grpc::CallOptions(headers, deadline, cancellationToken)));
}
/// <summary>
/// Creates, updates, or removes resources. This method supports atomic
/// transactions with multiple types of resources. For example, you can
/// atomically create a campaign and a campaign budget, or perform up to
/// thousands of mutates atomically.
///
/// This method is essentially a wrapper around a series of mutate methods. The
/// only features it offers over calling those methods directly are:
///
/// - Atomic transactions
/// - Temp resource names (described below)
/// - Somewhat reduced latency over making a series of mutate calls
///
/// Note: Only resources that support atomic transactions are included, so this
/// method can't replace all calls to individual services.
///
/// ## Atomic Transaction Benefits
///
/// Atomicity makes error handling much easier. If you're making a series of
/// changes and one fails, it can leave your account in an inconsistent state.
/// With atomicity, you either reach the desired state directly, or the request
/// fails and you can retry.
///
/// ## Temp Resource Names
///
/// Temp resource names are a special type of resource name used to create a
/// resource and reference that resource in the same request. For example, if a
/// campaign budget is created with `resource_name` equal to
/// `customers/123/campaignBudgets/-1`, that resource name can be reused in
/// the `Campaign.budget` field in the same request. That way, the two
/// resources are created and linked atomically.
///
/// To create a temp resource name, put a negative number in the part of the
/// name that the server would normally allocate.
///
/// Note:
///
/// - Resources must be created with a temp name before the name can be reused.
/// For example, the previous CampaignBudget+Campaign example would fail if
/// the mutate order was reversed.
/// - Temp names are not remembered across requests.
/// - There's no limit to the number of temp names in a request.
/// - Each temp name must use a unique negative number, even if the resource
/// types differ.
///
/// ## Latency
///
/// It's important to group mutates by resource type or the request may time
/// out and fail. Latency is roughly equal to a series of calls to individual
/// mutate methods, where each change in resource type is a new call. For
/// example, mutating 10 campaigns then 10 ad groups is like 2 calls, while
/// mutating 1 campaign, 1 ad group, 1 campaign, 1 ad group is like 4 calls.
/// </summary>
/// <param name="request">The request to send to the server.</param>
/// <param name="options">The options for the call.</param>
/// <returns>The call object.</returns>
public virtual grpc::AsyncUnaryCall <global::Google.Ads.GoogleAds.V6.Services.MutateGoogleAdsResponse> MutateAsync(global::Google.Ads.GoogleAds.V6.Services.MutateGoogleAdsRequest request, grpc::CallOptions options)
{
return(CallInvoker.AsyncUnaryCall(__Method_Mutate, null, options, request));
}
/// <summary>
/// Creates, updates, or removes resources. This method supports atomic
/// transactions with multiple types of resources. For example, you can
/// atomically create a campaign and a campaign budget, or perform up to
/// thousands of mutates atomically.
///
/// This method is essentially a wrapper around a series of mutate methods. The
/// only features it offers over calling those methods directly are:
///
/// - Atomic transactions
/// - Temp resource names (described below)
/// - Somewhat reduced latency over making a series of mutate calls
///
/// Note: Only resources that support atomic transactions are included, so this
/// method can't replace all calls to individual services.
///
/// ## Atomic Transaction Benefits
///
/// Atomicity makes error handling much easier. If you're making a series of
/// changes and one fails, it can leave your account in an inconsistent state.
/// With atomicity, you either reach the desired state directly, or the request
/// fails and you can retry.
///
/// ## Temp Resource Names
///
/// Temp resource names are a special type of resource name used to create a
/// resource and reference that resource in the same request. For example, if a
/// campaign budget is created with `resource_name` equal to
/// `customers/123/campaignBudgets/-1`, that resource name can be reused in
/// the `Campaign.budget` field in the same request. That way, the two
/// resources are created and linked atomically.
///
/// To create a temp resource name, put a negative number in the part of the
/// name that the server would normally allocate.
///
/// Note:
///
/// - Resources must be created with a temp name before the name can be reused.
/// For example, the previous CampaignBudget+Campaign example would fail if
/// the mutate order was reversed.
/// - Temp names are not remembered across requests.
/// - There's no limit to the number of temp names in a request.
/// - Each temp name must use a unique negative number, even if the resource
/// types differ.
///
/// ## Latency
///
/// It's important to group mutates by resource type or the request may time
/// out and fail. Latency is roughly equal to a series of calls to individual
/// mutate methods, where each change in resource type is a new call. For
/// example, mutating 10 campaigns then 10 ad groups is like 2 calls, while
/// mutating 1 campaign, 1 ad group, 1 campaign, 1 ad group is like 4 calls.
/// </summary>
/// <param name="request">The request received from the client.</param>
/// <param name="context">The context of the server-side call handler being invoked.</param>
/// <returns>The response to send back to the client (wrapped by a task).</returns>
public virtual global::System.Threading.Tasks.Task <global::Google.Ads.GoogleAds.V6.Services.MutateGoogleAdsResponse> Mutate(global::Google.Ads.GoogleAds.V6.Services.MutateGoogleAdsRequest request, grpc::ServerCallContext context)
{
throw new grpc::RpcException(new grpc::Status(grpc::StatusCode.Unimplemented, ""));
}