Buggy del sdata.table

[LucaMarconato]

After the planned io refactoring this problem will disappear. So not fixing this bug now, just tracking that we know it exists.

Currently if we try to delete a table we may get an error like this:

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
Cell In[73], line 1
----> 1 del sdata_patient1_visium.table

File ~/embl/projects/basel/spatialdata/src/spatialdata/_core/spatialdata.py:1090, in SpatialData.table(self)
   1088 store = parse_url(self.path, mode="r+").store
   1089 root = zarr.group(store=store)
-> 1090 del root["table/table"]

File ~/miniconda3/envs/ome/lib/python3.10/site-packages/zarr/hierarchy.py:464, in Group.__delitem__(self, item)
    463 def __delitem__(self, item):
--> 464     return self._write_op(self._delitem_nosync, item)

File ~/miniconda3/envs/ome/lib/python3.10/site-packages/zarr/hierarchy.py:895, in Group._write_op(self, f, *args, **kwargs)
    892     lock = self._synchronizer[group_meta_key]
    894 with lock:
--> 895     return f(*args, **kwargs)

File ~/miniconda3/envs/ome/lib/python3.10/site-packages/zarr/hierarchy.py:472, in Group._delitem_nosync(self, item)
    470     rmdir(self._store, path)
    471 else:
--> 472     raise KeyError(item)

KeyError: 'table/table'

[LucaMarconato]

This happens if sdata.table = table fails (for instance in this case #221) and then we call del sdata.table on it.

[LucaMarconato]

Closed by the multi-table PR #455 since it just deletes the table in-memory and not from disk.