-
Notifications
You must be signed in to change notification settings - Fork 362
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
Separate CacheMetadata class for CachingFileSystem #1326
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
I commented on the use of os.* functions, but maybe thoughts about allowing generic fsspec URLs should be deferred.
c["blocks"] = True | ||
|
||
def empty(self) -> bool: | ||
"""Return ``True`` if metadata of the writable storage is empty""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why only of the writable store?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only need to know if the writable store is empty following a call to CacheMetadata.clear_cache()
as if it is clear then the caller (CachingFileSystem.clear_expired_cache()
) deletes all of the writable cache and resets the cache access time, etc.
It is clumsy. I could just make the name better. But probably better still is to return a boolean from CacheMetadata.clear_cache()
to tell CachingFileSystem.clear_expired_cache()
whether the writable cache is empty. Then we wouldn't have an empty()
method hanging around waiting to be used incorrectly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the plan you describe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
The one failing test is indeed related to caching, but I can't tell if it's really failing or perhaps just the text of the error changed so the pyrest match got broken. |
The failure is a real one in |
56c9426
to
544006f
Compare
I solved the problem with |
This PR moves handling of cache metadata out of the
CachingFileSystem
and into a new classCacheMetadata
. The idea is for the metadata handling occur in one place so that we can easily modify and/or extend it in future PRs, e.g. to change the storage format or location.Essentially
cached_files
used to be a property ofCacheMetadata
but is now a property of the new class. BothCachingFileSystem
andCacheMetadata
need access to thestorage
locations, so this is shared between them.There is no functional change here. The only changes to the tests are due to the change in where the private
cached_files
are stored. There is one failing test that I haven't yet fixed, it istest_metadata_save_blocked
and is something to do with the hot-swapping of theopen
function that I don't fully understand.