If it returns it deleted if it throws an
If it returns it deleted if it throws an error it didn’t
7 Replies
Nope this is not the case, delete('unknown key') doesn't throw even if the object doesn't exists. it just sends undefined like a successful delete
anyone have another answer? perhaps @sdnts ?
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
Also FWIW S3 also returns success on delete even if the file doesnt exist
yup thanks, I just thought it would be nice to have a way to confirm a delete was successful or not, with delete sending back the deleted object. This would provide a better API than S3 in this sense.
I mean the delete of an object that doesnt exist technically is successful because it doesnt exist
Whats the use case for wanting to know if the item existed beforehand anyways?
Perhaps there are technical limitations about how this is implemented internally, and I would understand them. But in general knowing if a command was successful is a common need. For example if you if you use DELETE in postgresql then it's very precise.
Whats the use case for wanting to know if the item existed beforehand anyways?User experience (head sends the object or null for example, why not delete?) and reselling. I want to provide my customers a way to know how many objects were deleted, to do so I would need to know if a delete was successful. Which means, for now, doing an head() before a delete, but that's not good as it's subject to race conditions. As for the reselling need, perhaps having R2 logpush events would help (we would get ONE event for a deleted object even if there are multiple delete() for the same object going on).
Sending only one event would be very impractical it would have to be at least once to be useful.
But I still dont understand why knowing if something actually existed when deleted really matters tbh. I personally could care less if the item existed beforehand theres never been any use case I have where I want to know if it actually existed before.