Repository navigation
feat(Gax)!: refactor OperationResponse with OperationsClientInterface and CustomOperationsClient - #9753
feat(Gax)!: refactor OperationResponse with OperationsClientInterface and CustomOperationsClient#9753bshaffer wants to merge 14 commits into
Conversation
… and CustomOperationsClient
…nner snippet mocks
| $isStandardClient = $operationsClient instanceof OperationsClient | ||
| || $operationsClient instanceof OperationsClientInterface; |
There was a problem hiding this comment.
Is this really necessary? Isn't an instance of OperationsClient also an instance of the OperationsClientInterface?
There was a problem hiding this comment.
This was done so that we could support google/longrunning:0.4 in composer.json, as it will be google/longrunning:1.0 that adds support for OperationsClientInterface.
So, I think it's best to leave this as-is for now, with maybe the addition of a @TODO to say we can remove this once we drop support for google/longrunning:0.4
EDIT: After further consideration, I THINK we can go ahead and require google/longrunning:1.0 right away. The issue is, that package can't be released until AFTER we release GAX V2, so it's a bit of a chicken-egg situation
| ? $this->operationsClient | ||
| : new CustomOperationsClient($this->operationsClient, $options); | ||
| $lastProtoResponse = $customClient->toOperation($lastProtoResponse); | ||
| } |
There was a problem hiding this comment.
This means that if the $lastProtoResponse is not an instance of \Google\LongRunning\Operation we are transforming it into one.
From what I gather, Compute has its own custom LRO class, if we go ahead and perform this conversion and the end user loses access to the original object and methods that that object had, wouldn't it?
Preserve the raw custom operation response (e.g. Compute's Operation) for custom operation clients: - Store the raw response in CustomOperationsClient - Return the raw response in OperationResponse::getLastProtoResponse() with ?object typehint - Update MIGRATING.md to document the return type
- Use lastProtoResponse consistently instead of separate lastCustomResponse - Remove duplicate lastCustomResponse property from OperationResponse - Delegate to CustomOperationsClient::getLastProtoResponse() in OperationResponse
bshaffer
changed the title
bshaffer
changed the title
Add
OperationsClientInterface,OperationsClientWrapperInterface, andCustomOperationsClientto encapsulate custom LRO RPC options while preserving full backwards compatibility for GAPIC and custom LRO clients (e.g. Compute):Google\ApiCore\OperationsClientInterfaceandGoogle\ApiCore\OperationsClientWrapperInterfaceGoogle\ApiCore\CustomOperationsClientimplementingOperationsClientWrapperInterfaceOperationsClientWrapperInterfaceinOperationResponse::getOperationsClient()so custom LRO clients still return their underlying operations client$operationName(string) and$operationsClient(object) inOperationResponse::__construct()and tighten return types (getName(): string,getError(): ?Status,getLastProtoResponse(): ?object,getOperationsClient(): object)