* Allow LeanDataWriter to append to zip data files
* Use the data directory provided to the writer instead of the global value
* Disregard the time-portion of an input date
* Overwrite zip entries when creating futures data files
* Minor tweak and adding unit test
Co-authored-by: Martin Molinero <martin.molinero1@gmail.com>
The implementation here was stripping out the directories and unzipping to
a flat structure. This is not required and was breaking python algorithms by
messing up their folder based imports. Also, all consumers currently utilize
the return value which is a full list of the unzipped files including the sub
directories, so no changes were needed elsewhere.
Refactored IDataProvider interface to return stream. The IDataProvider
Fetch method now only takes a key. The IDataProvider
has been reshuffled to be at the bottom of the LeanDataStack. It provides
data to the rest of the Lean stack. The default implementation of IDataProvider reads
data from disc.
All IDataCacheProviders now have constructors which take IDataProviders
and use them to find data on disc.
Renamed DataCacheProvider to ZipDataCacheProvider
Added comments to IDataProvider and it's implementations
Added comments to IDataCacheProvider and it's implementations
Fixed bug where DataCacheProvider was returning a stream without closing
the stream. Also, ZipFiles returned from ZipFileCacheProvider are
effectively disposed.
Removed date field from IDataCacheProvider interface
This interface was built around the existing implementation of the
DataCacheProvider. It's purpose is to define a method for caching data
files. Currently, most data files are either read from disc or retrieved
remotely. The IDataChceProvider returns returns a Stream and can handle
many types of data. The IDataFileCacheProvider is needed because keeping data in memory will improve performance and overcome certain File read/write limitations (such as sharing violations) currently experienced by Lean.
There are two implementations of this interface. The first is the
SingleZipEntryDataCache. This is the default implementation. It does not
cache and returns the first entry found within a ZipFile. The second is
the ZipEntryCacheProvider. This is a rework of the existing
DataCachePrivider. It caches ZipFiles for up to 10 seconds. It can
return specific entries for option and future ZipFiles. Otherwise, it
returns the first entry in a ZipFile.
Added IDataFileCacheProvider as parameter to IHistoryProvider.Initialize()
The IDataFileCacheProvider is very useful for the IHistoryProvider in that it can eliminate the need for history request to touch disc. This can greatly improve peerformance and eliminate disc bugs associated with disc read/writes. To minimize changes throughtout Lean, the default value for the IDataFileCacheProvider is null in the IHistoryProvider.Initialize method.
IDataCacheProviders are passed down the Lean stack. Each instance of a Subscription Enumerator factory decides what cache it
will use. In other words, the IDataCacheProvider is not configurable from
config.json. The IDataCacheProvider is passwed down the stack form the
Enumerator factory to the IStreamReader where it is used to retrieve data.
Added useful helper method to Unizp files into a Stream.
This new overload allows the caller to specify every piece of data used by the
zip routine, allowing specification of the entry name, destination path, and
whether or not to delete the original file.
The replaced zip implementation had issues in high performance,
multi-threaded scenarios. The exact cause of the issue was not
determined, but invalid zip were being generated when using this
method directly.
The replacement uses the built in .NET zip archive implementation
which should (in theory) have better cross-platform characteristics
than 3rd party implementations.
The unit test was also update as it made incorrect usage of the
Compression.Unzip routine. It has been replaced with a more reliable
method that unzips the first entry and returns a stream reader.
This follows the behavior of logging when the file doesn't exist as well.
This is very common in options trade data, since it's often there are no trades for a contract
Many places in the code used Log.Error(err.Message) or equivalent which
strips out all the really useful information, such as the stack trace
and inner exceptions. Using Log.Error(exception) is the correct way to
log an error as it will correctly write all the message details, also,
by passing the full Exception object we can improve the logging in this
one place and all call sites will automatically benefit from the improvements
michael-sena