This way we can get trace-level information about the logger itself when
it is generated. Because from time to time we might want to have a look
at that.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Because the store is more efficient when reading and writing entries to
disk, we do not need to flush the cache anymore.
Hence, remove the flushing.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This is the merge for the "ref"-infrastructure rewrite. Finally.
The refs are now stored with three bits of information:
* The "collection" (named basepath)
* The "relpath" (relative path)
* The hash (sha1 as of now)
The "collection" is a name which has to be accociated with a path to a
directory (in the config file).
That gives the user the opportunity to have (for example) their music
collection in $HOME/music on one device and in $HOME/media/music on
another.
The "relpath" is the relative path, which results in the path to the
actual file when being joined with the "collection" path.
The hash is a sha1 hash as of now. Re-checking this hash with
libimagentryref is not yet tested.
This merge also removes the "mail" code completely, for the sake of
seperating concerns into branches. The respective commits might be
removed later.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
The documentation of the function kind of explains why this change is
necessary. It might get changed in the future so that the user has more
flexibility.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
* Remove old code
* Rewrite with tests
This implements a fassade pattern for ref library
With the fassade, we can specify the hasher in a rather easy way, which
is not possible with default generics for traits.
The "default" part in "default generic type" is not properly implemented
yet (as visible in the tests), as I don't know how to realize this.
For simplicity, the `hasher` module exports a `default` module with a
`DefaultHasher` type, which resolves to the `Sha1Hasher`.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
The function is for checking whether a flag is set. If the flag is not
available, the flag is obviously not set.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Finally merging the redefine of the StoreId implementation, which allows
easier handling of StoreId objects.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
imag-header is a tool for querying information of an entry in a defined
format.
imag-header is intended for scripting with imag commands.
The output format is not stable yet, though.
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>
When printing the storepath with the ID (when requested by the user), we
have to ask the store for its path.
This is a rather naive implementation which could be improved by only
checking for a boolean in the last iteration and then use a prepared
variable, rather than making the storepath part of the iterator.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
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>
