SamMousa
commented
5 months ago Is there any interest in making (any of) these adapters part of the core? We've been using them in production for years now and they are very stable. They are mostly tested and I'm happy to get the coverage up to (close to) 100%.
If not I think it's time to close this issue.
Feature Request
I have implemented several meta adapters to allow me to easily implement a virtual file system using different APIs and a compositional approach. A meta adapter is an adapter that takes an existing adapter and changes its behavior.
https://github.com/collecthor/flysystem-adapters
All of these are fully tested.
IndirectAdapter
Base class for meta adapters. Calls a function
preparePath()allowing for path rewriting. Calls a functiongetAdapter()to get the adapter to forward the request to.AddPrefixAdapter
An adapter that adds a prefix to all paths. I read about the
PathPrefixedAdapterand remembered I had created this repository and use it in production...MetadataCachingAdapter
This adapter caches metadata responses and serves them from memory. This is used in combination with some adapters like the one for Azure that will respond with all meta data. So when calling
lastModified()it will also return the visibility. When not using this adapter if you are generating a list of files with visibilities and last modification time you'll potentially get 4 times the number of API requests.DirectoryViaPlaceholderFileAdapter
Implements directory support for adapters not natively supporting it. Uses a configurable placeholder filename.
VirtualDirectoryListAdapter
Sometimes you might want to prepare a storage area for each entry in a table (think of a project uploads directory for each project). But when you have a lot of entries getting them from the remote API can be significantly slower than from the local database. Also, since in practice many projects might not actually upload files, you could lazily create the directory but still show all folders in a file manager.
OverlayAdapter
This implements mounting at the adapter level. So a virtual filesystem could mount different adapters at different paths, all transparent to the consuming filesystem instance.
StripPrefixAdapter
Strips a path prefix from all paths passed to an adapter.
I'm happy to keep them in my own repo or merge them into the core. Seeing as you were accepting other meta adapters in the changelog I thought people might be interested in these!