[Spring]FixIllegalStateExceptionForDelete

[xinlian12]

Fix issue #38917

Fix: avoid using .block/.blockLast in our reactive pipeline - As documented here https://github.com/reactor/reactor-core/releases/tag/v3.2.0.M2.

[azure-sdk]

API change check

API changes are not detected in this pull request.

[FabianMeiswinkel]

LGTM

[xinlian12]

/azp run java - spring - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[edavedian]

@xinlian12 thank you very much for addressing this issue. I have a follow up question. The statement

new PartitionKey(entityInfo.getPartitionKeyFieldValue(object)),

in the area that the fix was, is obtaining the partition key value from the instance of the domainType that was created a few lines above with this statement

CosmosEntityInformation<T, Object> entityInfo = (CosmosEntityInformation<T, Object>) CosmosEntityInformation.getInstance(domainType);

This instance though since it was just instantiated won't have any value for partition key unless I am misunderstanding the approach. The same issue exists in findItems method. Would it be possible for me to create an enhancement request to support something like

deleteByNaId(String naId, PartitionKey partitionKey);

and use this partition key during findItems and delete methods.

[xinlian12]

Hi @edavedian - I think all we looking for from entityInfo is what is the partitionKey field, because it kind decides underlying we use bulk or not. Does this answer your question? if not can you elaborate a little bit more, I do not think I get the problems there, thanks

[edavedian]

@xinlian12 thank you very much for your reply. You are correct as far as if (entityInfo.getPartitionKeyFieldName() != null) {. But once a partition key field name exists then later it creates a new ParitionKey object by doing

new PartitionKey(entityInfo.getPartitionKeyFieldValue(object)),

to try to extract the value of the partition key to be used during the query or delete operation. Isn't the value specified by new PartitionKey(entityInfo.getPartitionKeyFieldValue(object)) used by Cosmos to execute the operation on that specific partition?

Similar logic exists in findItems as follows:

Optional<Object> partitionKeyValue = query.getPartitionKeyValue(domainType);
partitionKeyValue.ifPresent(o -> {
      LOGGER.debug("Setting partition key {}", o);
      cosmosQueryRequestOptions.setPartitionKey(new PartitionKey(o));
 });

If the value of the partition key is used by Cosmos to execute the operation on that specific partition, what I am trying to convey is that the mechanism in which the value of this partition key is retrieved is inaccurate.

Again, I may be misunderstanding the code but they way I read it is trying to obtain the value of the partition key in findItems and delete methods to be used to specify the partition key in CosmosQueryRequestOptions and CosmosBulkItemRequestOptions settings before executing the actual query or delete operations.

[xinlian12]

Hi @edavedian

final Flux<JsonNode> results = findItems(query, finalContainerName, domainType);
this is the first step happened to retrieve all the items need to be deleted. The partitionKey is retrieved from the cosmosQuery based on the partitionKeyField in the domainType.

so in your scenario Mono<Void> deleteByNaId(String naId); , the cosmosQuery here will contain criteria naId = naId(the value passed in), and then we tried to parsing the partition key value based on the criteria. However, since in your case naId is not the partition Key, so essentially this will be translated into a query"select * from naId = {naId}" and this will be a cross partition query.
After we get all the items from the above step, then we will go ahead to delete them, here when we calculate the partitionKeyValue, we use the value from the items.

If I understand correctly, the issue you pointed out is that in step one, it will be a cross partition query as no partitionKey value is being defined, whether we can support to accept a partitionKey value as well. I think it is a valid ask, please feel free to create a GitHub feature request and our team will evaluate it :)

[edavedian]

@xinlian12 Thank you very much. I will created a feature request.

[edavedian]

@xinlian12 I have submitted the feature request #39331 based on our conversation.