This is a more complicated functionality (implementation-wise) of the
`Entries` iterator, which allows a callee to transform it into a
`StoreIdIterator`.
It uses the crate internal `PathIterator` type and a function to extract
the internals of that iterator which is then turned into an iterator
over `Result<StoreId>`, which can be used to build a `StoreIdIterator`.
The implementation is ugly, but we need to be able to transform a
`Entries` iterator into a `StoreIdIterator` in the
`libimagentryannotation`, and possibly in more cases where we want to be
agnostic over iterators.
Maybe there is a cleaner solution to this, hence the comment about
whether this should be removed.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this change applied, libimagstore does not export backend
representing types anymore.
This change is necessar because when we want to switch the `StoreId`
implementation from "complex and stateful" to "Stateless and Cow<'_,
&str>", we need to be able to have a type which represents a "`StoreId`
plus the path of the Store itself".
This "the path of the Store itself" is passed around as reference, to
minimize runtime impact.
Because such a type should not be exported by the libimagstore crate, we
make it `pub(crate)` internally. But because the backend APIs also have
to use this type, we would export the (private) type in the APIs of the
backend.
Because of that we make the backend API also non-visible to crate users,
which also decreases the surface of the libimagstore API itself.
Besides:
Remove function `Link::with_base()` which is not needed anymore (was
used in tests only).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This changes the implementation of the StoreId type to be less complex.
Before we always had to re-attach the path of the store itself each time
a StoreId object was passed to the store. Now we do not do this anymore,
hopefully we can move to a implementation of the Store API which takes
references of StoreId objects in the future.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
When printing the error chain, we print the error and then iterate over
the causes. Hence, we have to increase the printed number by one here,
because 0 (zero) is already printed.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch fixes a bug where the following code (here pseudocode) did
the wrong thing:
store.entries().in_collection("foo").for_each(||...)
because the `.in_collection()` call for the underlying PathIterator
object did not actually re-build the iterator. It only changed the
contained `PathIterBuilder`, but did not call `.build_iter()` on it to
rebuild the iterator object.
The test added with this patch checks whether the iterator does the
right thing.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
We Iterator::filter here, so we have to negate - because we list
everything where _no_ instance exists yet.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch changes generate_variants() so that it allows to be passed an
iterator for the modders, which makes it more powerful for passing
references.
When listing timetrackings, we do not want to print an empty table if
there aren't any timetrackings.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch adds a wrapping functionality to imag-log.
The commandline parameter `-w` or `--wrap` can not be used to wrap the
output at N characters, defaulting to 80 characters.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch removes the magic constant we used when calling
`trace_unwrap_exit()` or `map_err_trace_exit_unwrap()`.
We used to call it with `1` as parameter, where the number was the exit
code to use. Now the implementation of the function does it
automatically (using 1 (one) as exit code).
All calls of these functions were fixed. Thanks to vim this was easy.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
We should be able, from the signature of the `generate_variants()`
helper function, to pass a `Vec<&T>` here, so cloning should not be
necessary.
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>
This way we alter the underlying iterator for all contacts to only
iterate in the "contact" 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.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This is a small optimization so that we do not print the information if
the output is a pipe anyways.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Because this API only errors when write!() errors occur, we can return
the exit code as an error here.
This way the user of the API can immediately exit if there was an IO
error, but the API automatically takes care of the right return value,
returning (exiting) with zero (0) if there was an "Broken pipe" error
and with one (1) otherwise, which is the expected behaviour here.
All calls to that API were changed accordingly.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch rewrites how imag-annotate iterates over the ids to process
to be more easily to understand.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this patch, libimagentryannotation does not have special iterator
types anymore. This makes the whole thing more comfortable to use.
In imag-annotate, the parameter for the functioncall was removed.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Because before we created a new annotation for each ID to be annotated,
which is not the expected behaviour.
Now we create one annotation object and then link it to all IDs which
are provided on the commandline.
Also, the annotation name is printed.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
It makes no sense to name annotations, a user only cares about whether
there are annotations or not, or their contents. A name has no meaning
in this context.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
