This patch refactors the output part of the IO backend into an own
backend which is simply used by the IO-backend.
This way we can have a pure-output backend.
This commit changes the backends to do less de/ser, as it now stores the
Entry objects in the backend and does the de/serialization there.
This means the store does only serialize things once from json to toml
in the io backend.
See the diff of the documentation for more details.
This commit implements a backend which reads from a Read when created
and writes to a Write when dropped.
This way, one can initialize stores which are build from commandline
feeded JSON or TOML (currently JSON is implemented/about to be
implemented).
The title might be a bit inaccurate, but I cannot think of something
better.
Before the change
=================
Before this change, we had a compiletime backend for the store. This
means that the actual filesystem operations were compiled into the store
either as real filesystem operations (in a normal debug or release
build) but as a in-memory variant in the 'test' case.
So tests did not hit the filesystem when running.
This gave us us the possibility to run tests concurrently with multiple
stores that did not interfere with eachother.
Problem
=======
This approach worked perfectly well until we started to test not the
store itself but crates that depend on the store implementation.
When running tests in a crate A that depends on the store, the store
itself was compiled with the filesystem-hitting-backend.
This was problematic, as tests could not be implemented without hitting
the filesystem.
After the change
================
After this change, the backend code is injected into the store via
dependency injection (the `Store::new()` function automatically uses the
filesystem-backend).
The store can be created with a the in-memory backend when running tests
now.
Implementation
==============
The implementation of this is rather stupid, despite the big diff in
this commit.
Lets have a look at the `Store` code changes first and then we'll
discuss the `file_abstraction` changes this commit introduces.
libimagstore::fs_abstraction
----------------------------
The filesystem was abstracted via a trait `FileAbstraction` which
contains the essential functions for working with the filesystem.
Two implementations are provided in the code:
* FSFileAbstraction
* InMemoryFileAbstraction
whereas the first actually works with the filesystem and the latter
works with an in-memory HashMap that is used as filesystem.
Further, the trait `FileAbstractionInstance` was introduced for
functions which are executed on actual instances of content from the
filesystem, which was previousely tied into the general abstraction
mechanism.
So, the `FileAbstraction` trait is for working with the filesystem, the
`FileAbstractionInstance` trait is for working with instances of content
from the filesystem (speak: actual Files).
The `FileAbstraction` trait requires a function to be implemented that
can be used to create a `FileAbstractionInstance` object from it.
In case of the `FSFileAbstractionInstance`, which is the implementation
of the `FileAbstractionInstance` for the actual filesystem-hitting code,
the underlying resource is managed like with the old code before.
The `InMemoryFileAbstractionInstance` implementation is corrosponding to
the `InMemoryFileAbstraction` implementation - for the in-memory
"filesystem".
The implementation of the `get_file_content()` function had to be
changed to return a `String` rather than a `&mut Read` because of
lifetime issues.
This change is store-internally and the API of the store itself was not
affected.
libimagstore::store::Store changes
----------------------------------
So, first we need to make sure that the store knows the actual backend.
Therefor, the `new()` method was renamed to `new_with_backend()` and got
another parameter: the backend implementation.
A new `new()` function was created for convenience and
backwards-compatibility with the rest of the imag codebase (and also
because nobody wants to pass the backend manually all the time).
As the backend is abstracted via a trait, and the store should not
change its interface, the new `Store` member was introduced inside a
`Box`.
All calls (`remove_file()`, `copy()`, `rename()` and `create_dir_all()`)
were refactored from `FileAbstraction::*` calls into `self.backend.*`
calls.
libimagstore::store::StoreEntry changes
---------------------------------------
The `StoreEntry` type is constructed in the store internally for holding
a `StoreId` object as well as some status and the file abstraction code.
This object is constructed via a `new()` function that got a new
parameter: a `&Box<FileAbstraction>` to the backend abstraction the
store uses.
This backend is now used to create a new `FileAbstractionInstance`
object for the `StoreEntry`.
Also the `StoreEntry::get_entry()` code had to be adapted to the new
`Entry::from_str()` function interface.
This commit message is partially added as comment in the code.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
