Deleting attributes on records while another update might change other attributes of same record in parallel

Hi!
Given the following situation: I am in a distributed event-based system. I have an index with multiple independent applications asychronously doing partial updates on parts of the records, running in parallel.
All partial updates do write their own timestamps of their last update event into dedicated fields. Those timestamps are used together with IncrementSet, to maintain update order integrity.

My Goal: I want to get rid of a top-level attribute on all records of this index.

As I wanna remove a top-level attribute, partial updates do not solve my issue - from what I know. They seem not to be capable to delete existing attributes.

So it needs to be saveObject(). But with that, I need to write full records. Then, I do not know any solution how I can ensure update integrity.
Situation in my mind: My field removal script runs. It fetches a batch of records and calculates the desired record state with a field less, then writes back the new state of record via saveObject. In the meantime, a different script does a partial update on the same record. That update will be lost as soon as saveObject hits with the old state.
So I need something in the style of transactions (so nobody gets between read and write) or something to maintain the order of updates. With Algolia, I have so far chosen the latter aproach.

Now my question: Is there any approach to delete fields on top-level while still maintaining update order integrity?
Partial updates with IncrementSet were great, but for top-level field deletion I need saveObject and have not found an alternative to IncrementSet or IncrementFrom yet.

Thank you!

You could set the attribute value to blank using a partial update, but you are correct that to remove the attribute completely, you’ll need to re-write the full record using a saveObject() call.

This will require you to either disable your partial updates while you run the script to clear the attribute form all records, or instantiate some sort of external locking mechanism if you intend to do the updates in batches.

I’ll reach out internally to see if there are any recommended patterns here I may not know.

1 Like