Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Solved) bug with io and lazy loading #117

Closed
LucaMarconato opened this issue Jan 26, 2023 · 2 comments
Closed

(Solved) bug with io and lazy loading #117

LucaMarconato opened this issue Jan 26, 2023 · 2 comments

Comments

@LucaMarconato
Copy link
Member

Noticed when working with the io of transformations and fixed in #100 (gonna close the issue when the pr is merged), but worth mentioning the bug here so that you are aware of that behavior.

The bug fix consists in the following: when an object is backed (=images, labels and points; not shapes or polygons, nor table (since it's an anndata)), after it is written, we immediately read that element from disk. If we don't do this there could be confusion cases like the following:

  1. we write a SpatialData object with images/labels/points to disk
  2. we load the object into a separate object, let's call it s. Now self.path
  3. we write s to a different zarr storage; this will change self.path to the new file storage, but the in-memory object would still pointing to the old one.

I will now make a commit with tests against the behavior described above.

@LucaMarconato
Copy link
Member Author

Tests added.

@LucaMarconato
Copy link
Member Author

Clarification is shed onto this case thanks to the new __repr__() and is_self_contained() method in #501, which warn the user when a mismatch between backed files and Zarr storage happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant