There is and IncrementSet and IncrementFrom operator that is available in the partialUpdateObject() function. I would really like to use it on saveObject(). Is there any reason it is missing there?
I’m Dorian, software engineer at Algolia.
What you can do with SaveObject() you can do with PartialUpdateObject(): the point of PartialUpdateObject() is to be able to add or replace only some attributes and leave the other attributes intact, but nothing is stopping you from replacing the whole object with all of its attributes.
Of course, since SaveObject() replaces entirely existing records, you would need to be careful with PartialUpdateObject() that you don’t end up with stale attributes.
Does that answer your question?
That does not answer my question at all.
Can you please re-read the question? This is a question about using incrementSet in the saveObject() function (and not about the difference between saveObject() and partialUpdateObject()).
Are you intending to use incrementSet and incrementFrom with saveObject so that you can remove some of the attributes while also incrementing others?
If you are not intending to remove any of the attributes, then Dorian’s suggestion would apply as nothing prevents you from using partialUpdateObject() across every attribute.
If you are in fact looking to increment some attributes and remove others simultaneously, then unfortunately no I don’t believe saveObject has that capability. I believe it could be done in two steps – save to remove the attributes, then increment with partialUpdate. Or perhaps manually in client-side logic (fetch, calculate and update, then save.)
Does this answer your question?
I want to use saveObject() and not partialUpdateObject() because I don’t know whether the object is already in the index. saveObject() works either way, but partialUpdateObject() seems to be a no-op if the object is not the index.
IncrementFrom only work for
partialUpdateObject() because it needs a base value to be applied on for working. This is the reason why it’s not possible to apply it on
saveObject() is meant to create an object. I’m not sure what your use case is but it seems like you will have to do it in two steps as @kevin.sullivan suggested indeed.
If you need more guidance you can explain your use-case, but it’s sure that you won’t be able to do what you explained us in your first message unfortunately.
The documentation explicitly says that saveObject() creates an object if it does not exists, AND UPDATES it if it does not. Since saveObject() can also update objects, it makes sense to implement IncrementSet and IncrementFrom to guard against out of order updates, just as in partialUpdateObject(). As it stands now, saveObject() is unsafe in a concurrent environment (and what web service is not concurrent?). The natural semantics for it would be:
- Create the object if it does not exists.
- If it does exist and IncrementSet indicates a later version, update the object.
- If it does exist and IncrementSet indicates an earlier version, don’t do anything.
The use case we have is that we have a recurring task that syncs our objects to Algolia. When we retrieve the object from our database, it is not clear if Algolia already has the object and we need to create it, or if it is just out of sync and we need to partial update it. saveObject() lets us deal with this situation because it also has update semantics, but without IncrementSet it opens up the concurrency issues.
We are going to have to implement tedious, error-prone, otherwise completely unnecessary bookkeeping on our end simply to keep track of what data we already sent to Algolia and what we have not. If saveObject() had concurrency checks, it would make things so much simpler.
Unfortunately, the saveObject() operation doesn’t support the per-field update you expect.
The workaround I can propose is to save/update your objects using multiple partial update operations with one API calls setting
createIfNotExists parameter to
By doing this, if the object doesn’t exist, it will be created by the first update operation. The next update operations will just update this object while you can take the advantages of
IncrementFrom update operations.
Oh, that’s what I was looking for! I didn’t realize there was a