This patch changes the Entries::in_collection() interface to return a
Result<()>. This is needed because the fs backend implementation should
be able to check whether a directory actually exists whenever we change
the iterator.
If the implementation detects that the directory does not exist, we can
fail early and error out.
All usages of the interface are adapted by the patch as well.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this patch we move the codebase to Rust-2018.
The diff was generated by executing
cargo fix --all --all-features --edition
on the codebase.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Because the code was so complex before, we had to create an object and
then cast that object into a `StoreId` rather than just creating a
`StoreId` object right away.
With this patch, we're using the code-generation approach to generate a
function that creates a `StoreId` object based on the name of the
current module. That's way easier and error handling was also improved
by the switch to the new implementation.
The patch also includes a rewrite of all usages of ModuleEntryPath and
changes them to `module_path::new_id()` calls.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
because we return `libimagstore::iter::Entries` here now, we do not have
to pass the store anymore.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This way we alter the underlying iterator for all wiki entries to only
iterate in the "wiki" collection of the store, which results in fewer
disk access because the internal iterator does not yield all pathes from
the store before filtering them.
Code which was used to implement the filter was removed (also from the
public interface of the library).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
to also return the index page. This way a user of the library can use
the index page entry right away.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
The previous iterator was implemented to simply fetch _all_ pathes from
the filesystem, no matter what.
With this implementation, this changes. The iterator now has
functionality to optimize the iteration, if only a subdirectory of the
store is required, for example `$STORE/foo`.
This is done via functionality where the underlying iterator gets
altered.
First of all, the interface was changed to return a `Entries` object,
which itself only covers the libimagstore-internal `PathIterator` type.
This type was changed so that the backend implementation provides an
"PathIterBuilder`, which builds the actual iterator object for the
`PathIterator` type.
The intermediate `StoreIdConstructingIterator` was merged into
`PathIterator` for simplicity.
The `Entries` type got functionality similar to the
`StoreIdIteratorWithStore` type for easier transition to the new API.
This should probably be removed at a later point, though.
As the `walkdir::WalkDir` type is not as nice as it could be, iterators
for two collections in the store could be built like this (untested):
store
.entries()?
.in_collection("foo")
.chain(store.entries()?.in_collection("bar"))
Functionality to exclude subdirectories is not possible with the current
`walkdir::WalkDir` implementation and has to be done during iteration,
with filtering (as usual).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Matthias Beyer