Raise an exception for previously set key

[maxrjones]

I think this tests was not correctly checking the behavior because the data at k was previously set, so calling set_if_not_exists on that same key should actually raise an exception. The behavior for obstore in #1661 and kylebarron#3 seem correct, in contrast to the fsspec-based stores which now fail on this test.

[d-v-b]

can we be more specific about the exception? Ideally we would match the type and the error message

[maxrjones]

I'm not quite sure how to manage matching the type with optional dependencies. Obstore raises its AlreadyExistsError and fsspec raises its FileExistsError. One option is to put this as NotImplemented in the base test class and require the individual stores to implement it in their tests, but that seems non-ideal. Do you have advice?

Matching the error message would be easier because we wouldn't need to import those errors.

[d-v-b]

if it's not simple to get more specific than Exception than I think it's OK to leave it as-is, and i can open an issue about how we could make this particular test more specific 😄

[maxrjones]

@d-v-b when looking into what exceptions fsspec raises, I noticed that fsspec's internal code comments and the docs lists exclusive write as experimental and risky. Should we warn about this in the Zarr docs?

[d-v-b]

@martindurant what do you think?

[jhamman]

so calling set_if_not_exists on that same key should actually raise an exception.

I don't know if this is the behavior we want actually. The application in Zarr that relies on this method is to set an empty group metadata object if it doesn't exist yet. If it does, the desired behavior is to move on.

One way to move forward is to catch this error in the Obstore Store and then move on.

[maxrjones]

so calling set_if_not_exists on that same key should actually raise an exception.

I don't know if this is the behavior we want actually. The application in Zarr that relies on this method is to set an empty group metadata object if it doesn't exist yet. If it does, the desired behavior is to move on.

One way to move forward is to catch this error in the Obstore Store and then move on.

Thanks Joe, that makes sense now. I'll follow your recommendation to suggest a change within ObjectStore instead