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

Discussion: how incremental addition/modification of elements and IO interact #186

Closed
LucaMarconato opened this issue Mar 14, 2023 · 4 comments · Fixed by #501
Closed

Discussion: how incremental addition/modification of elements and IO interact #186

LucaMarconato opened this issue Mar 14, 2023 · 4 comments · Fixed by #501

Comments

@LucaMarconato
Copy link
Member

LucaMarconato commented Mar 14, 2023

This is to collect points to discuss in major redesign of how IO interacts with the capabilities of extending an object by adding/removing or modifying particular elements. In other words, we need to decide how the user can modify/extend a SpatialData object after its constructor is called, and how this relates with IO.

It evolves from previous discussions in this old issue #137 (and it's related PR #138).

I'll just dump all the points and reformat later on.

  • comments on add_image(), add_labels()
    • these functions are immediately writing to disk when called. We could decide removing these functions and let the user write to disk explicitly. But it would be cool to know what is to be written to disk, and what not.
    • the functions also check if the name of the image being added is already present in sdata.images or not, or if it is unique across all elements. This check is important, but currently it can be overridden by simply doing sdata.images['my_image'] = image. We should decide on one of the following:
      • we make .images private and we remove sdata.add_images('my_image', image). The user will not use sdata.images['my_image'] anymore, leaving only with the option to do sdata['my_image'] = image, which internally uses get_schema() to know what image is.
      • we replace .images with an accessor class for which we override __set_item__() and __get_item__(), and we make these __set_item__() call add_image() internally.
@LucaMarconato LucaMarconato changed the title Discussion: how incremental addition/modification of elements and IO Discussion: how incremental addition/modification of elements and IO interact Mar 14, 2023
@LucaMarconato
Copy link
Member Author

We also need functions to remove elements, not just in-memory but also on disk.

@LucaMarconato
Copy link
Member Author

In the end we went for the accessor option and we separated the phase of adding new elements in-memory and writing them to disk.

@ivirshup
Copy link
Member

Semi related, and might be of interest:

Basically, making it easy to cache new elements to disk without modifying any existing on disk data.

@LucaMarconato
Copy link
Member Author

Thanks for sharing, very interesting!

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

Successfully merging a pull request may close this issue.

2 participants