Suppose I issue a
delete_by request on my index’s
distinct_key:1234 which currently has records with
["A", "B", "C", "D"] and then issue a
save_objects request with
["C", "D", E"] all also having
How does Algolia handle these two requests? My desired outcome is for
["C", "D", E"] to be saved and for
["A", "B"] to be deleted.
The “Automatic update for split records” section in the Wordpress “Splitting Large Records” integration article here got me curious about how algolia handles asynchronous deltes and updates on the same objectIDs.
I have a large object that is split into several records in Algolia. Updating this object requires not just sending the newly generated records, but also deleting the old ones in case the way the object is chunked into records changes.
Currently for updating these objects we do the following:
- Synchronously retrieve the list of existing objectIDs in Algolia corresponding to the object (our
- Generate split records w/ objectIDs for the object
- Issue a delete_objects request to delete existing objectIDs that don’t exist in our generated records’ objectIDs (without waiting for the task to complete)
- Issue a save_objects request to save the generated records (without waiting for the task to complete)
The need to request objectIDs from Algolia before the requests can be issued is a bottleneck. However the article I mentioned makes me think issuing the delete on only the
objectIDs that should be deleted may not be necessary.
When updating a post, it can potentially become shorter and take fewer records. This means you need to delete old records for a given post before indexing the new ones. You can delete all records for a given post by using the
deleteBymethod on the