Spring Cosmos - Support patch/partial update

[z1069867141]

cosmos is a document DB, and one record could be large. Sometimes it's desired to only update part of the document instead of the whole document.

This story is to support the partial patch update to one cosmos document.

[kushagraThapar]

Cosmos is waiting for Bulk / Batch / Patch GA, once that is done, this can be implemented in spring.

[Manuel-Moya]

Patch is GA :)

[kushagraThapar]

@Manuel-Moya - yes, it is GA now, will be released in Java SDK v4.21.0 sometime next week. Once that is out, we will start building support for it in spring-data-cosmos SDK.

[sachinadiga]

@kushagraThapar any progress on this? what is the timeline we have by which this can be implemented.

[MihaiTudorP]

Hello, is there any update on this? It's been some time since the 3rd of November, 2021, with nothing here. Any roadmap milestones or estimated release in which this will come out for Spring? The Cosmos feature has been available for quite some time now.

[backwind1233]

Hi @kushagraThapar, is there any updates you can share with MihaiTudorP?

[kushagraThapar]

@MihaiTudorP - apologies for the missed update. We do plan to pick up Patch API work in this semester and plan to deliver it early next year after the holidays.
Since we are still looking into the design phase, I am wondering if we can collect some design input from you. And the most important question being how do you plan to use Patch API in spring data cosmos SDK? Since spring-data abstracts out most of the database components, exposing Patch API is going to be interesting from design point of view.
cc @TheovanKraay
@trande4884, can you please take this discussion forward?

[MihaiTudorP]

@MihaiTudorP - apologies for the missed update. We do plan to pick up Patch API work in this semester and plan to deliver it early next year after the holidays. Since we are still looking into the design phase, I am wondering if we can collect some design input from you. And the most important question being how do you plan to use Patch API in spring data cosmos SDK? Since spring-data abstracts out most of the database components, exposing Patch API is going to be interesting from design point of view. cc @TheovanKraay @trande4884, can you please take this discussion forward?

Hi, @kushagraThapar , thank you very much for the swift update. Do you have also an estimated date of delivery for this, so that I can plan the version upgrade on my project? Also, if you need input, I will provide the needed information, just say what design-related info you need for this in order to develop the patch.

[trande4884]

@MihaiTudorP we do not yet have an estimated date of delivery, I will update here once we do

[TheovanKraay]

@MihaiTudorP as Kushagra mention, we would also really like to collect some design input from you.

The most important question being: what is your motivation for wanting to use patch api in Spring?

If, for example, the motivation is to save on RU costs from doing replace(), keep in mind that the RU cost for patch() is equivalent to the RU for replace() because the physics in terms of physical resources (cpu, memory, etc.) are roughly the same. The cost savings for patch() compared to replace() will come from avoiding the RU cost for a read() and cpu/memory burned on the application that comes before replace(). For example, if I want to update a property – I can either:

1. Send a patch()

Or

2. read() the document + patch within the application tier + replace() the document

Typically Spring users are not needing to do #2 and so there is no benefit in this space. However, another major benefit for patch is avoiding etag contention from highly concurrent updates.

hence, any feedback on your motivation and use case for using patch, and how you expect it to benefit you, will be greatly appreciated! Thank you.

[MihaiTudorP]

@TheovanKraay my motivation is to improve overall application performance (sending less data should improve processing speeds) and avoid etag contention from concurrent updates. Also, less time on the network for sensitive data.

[arunim29]

@TheovanKraay @kushagraThapar is there a way to use vanilla cosmos client provided by cosmos sdk along with spring data cosmos. Basically, share the same cosmosClient instance. With this, we can use the best of both worlds.

I could not find a way because spring data cosmos expects a bean of cosmosClientBuilder instead of cosmosClient. If it would have been cosmosClient, I could have shared the instance. Any idea on how to achieve this?

[TheovanKraay]

@TheovanKraay my motivation is to improve overall application performance (sending less data should improve processing speeds) and avoid etag contention from concurrent updates. Also, less time on the network for sensitive data.

Hello @MihaiTudorP, in order to help with design of this, we have a few follow up questions:

1. Is your expectation to use patch via CosmosTemplate or the Repositories?
2. Are you planning to use Reactive Spring or Spring?

[TheovanKraay]

@TheovanKraay @kushagraThapar is there a way to use vanilla cosmos client provided by cosmos sdk along with spring data cosmos. Basically, share the same cosmosClient instance. With this, we can use the best of both worlds.

I could not find a way because spring data cosmos expects a bean of cosmosClientBuilder instead of cosmosClient. If it would have been cosmosClient, I could have shared the instance. Any idea on how to achieve this?

You can access Cosmos client directly. To do this, autowire ApplicationContext bean and then use it to get any bean that is created by cosmos client or by spring:

@Autowired
private ApplicationContext applicationContext;

Then in your application, you can do this ->

final CosmosAsyncClient cosmosAsyncClient = applicationContext.getBean(CosmosAsyncClient.class);

One of our unit tests show how to do this: https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-spring-data-cosmos-test/src/test/java/com/azure/spring/data/cosmos/repository/integration/PageableAddressRepositoryIT.java#L153

[arunim29]

@TheovanKraay thanks for a quick reply. I have some follow-up questions :

Any reason why cosmosclient is made private? I am asking because the builder is provided anyways by the application. So, you get all the config from the application. Correct me if I am wrong -> in spring data for relation dbs, spring data takes datasource bean from application and that bean can be used in parallel by the application code as well.

[TheovanKraay]

@TheovanKraay thanks for a quick reply. I have some follow-up questions :

Any reason why cosmosclient is made private? I am asking because the builder is provided anyways by the application. So, you get all the config from the application. Correct me if I am wrong -> in spring data for relation dbs, spring data takes datasource bean from application and that bean can be used in parallel by the application code as well.

Corrected myself. You can access the client directly. See above.

[TheovanKraay]

Note: this is only possible for CosmosAsyncClient, because we don't create a bean of CosmosClient.

[arunim29]

@TheovanKraay if u do not create bean of CosmosClient, which cosmos client do you use to support normal crud repositories which are not reactive.

[TheovanKraay]

@arunim29 non-reactive Repository still uses CosmosAsyncClient behind the scenes, but with blocking calls. CosmosClient is not used by Spring Data Cosmos library.

[arunim29]

@TheovanKraay got it. Thanks for the help.

[TheovanKraay]

@arunim29 - as posted in separate issue #32390 - we plan to expose patch something like the below. Let us know if this is not what you expect. Feel free to make suggestions or ask questions here.

CosmosPatchOperations patchOperations = CosmosPatchOperations
    .create()
    .replace("/size", 5)
    .add("/color", "blue");

User patchedUser = userRepository.save(user,patchOperations,null);