Cache attributes #77
Cache attributes #77
Conversation
Avoids frequent reading and parsing of JSON encoded attributes, this is most interesting for high latency backends. Changes of attributes by an independent writer will not be tracked, so some consideration required.
writer are consistent in cache and on disc
auto-generate current year in license
sensitive ops twice with a caching writer)
TODO implement updates in create and remove methods
TODO shouldn't readers do that too?
TODO fails deepList test for a mix of test and implementation issues
# Conflicts: # README.md # pom.xml
abstracts further to platform dependent separation strings (e.g. "/" vs "\"). The resulting path string is now strictly a platform dependent path and should not be used in code where a platform independent string is expected. Thanks to the Windows FileSystem implementation accepting "/" separated paths, this should not cause pracitcal issues at this time but we may have to change the API to support other FileSystems (e.g. passing paths along as components instead of strings or settling on a nio Path like object).
better on key value stores that do not really have paths. TODO check for leftover redundant path creation, that wouldn't break things but makes an unnecessary exists test
|
In talking with @cmhulbert , it may be that we want to use Edit: see https://github.com/saalfeldlab/n5/tree/cache-normalization |
* instead return null * test primitive parsing
|
Currently we're seeing this behavior here N5Writer n5 = ...
n5.setAttribute(groupName, "key", 0.1);
n5.getAttribute(groupName, "key", Integer.class )); // returns 0 (i.e. rounds rather than return null)The issue seems to be deep in Gson |
* edit documentation * to reflect current impl in N5KeyValueReader
* implement N5Reader interface method
* helpful for zarr impl and perhaps generally
|
@cmhulbert will want to ask you about this when you have time 7c37cf9 |
|
Re the discussion on zulip, We could consider adding a protected constructor to https://github.com/saalfeldlab/n5/tree/kv-reader-cons |
|
@axtimwalde , branch of interest: https://github.com/saalfeldlab/n5/tree/wip/KeyValueInterface
@cmhulbert ,
|
|
I ran this benchmark comparing the current master a1fcd2f to the latest development commit d14fe55 . In summary: they're comparable. current masterlatest development |
Filesystem abstraction and meta data caching