After moving an entry, the entry should _not_ be in the cache. This is
just a decision that has to be made, whether we cache the moved entry or
not. I decided to not cache because it is results in less code.
After that check, we get the entry from the backend and then we can
check whether the entry is in the cache, which is then should be.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
When moving an entry, what we did is copying the entry inside the
backend abstraction (the hashmap) from one key to another.
But as the entry itself does also encode its location, we actually have
to rewrite the entire entry. This patch fixes this.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This is a bugfix for a bug in Store::move_entry_by_id():
The old entry was not removed after the new one was created.
The bug is a bit subtle. The issue was, that the internal cache held
open a reference to the old entry (as StoreEntry object) and when that
object got drop()ed, the contents of the entry were written to disk,
which resulted in the old entry being recreated.
This patch rewrites the function to behave well. The most critical part
is that we do not check whether the old entry is borrowed with
`hsmap.get()` but rather `hsmap.remove()`. The trick here is that the
`StoreEntry` object is dropped in the moment the check is done, clearing
the cached object and flushing it to the backend (the disk).
After that, we continue doing the filesystem operation and the cache is
clean.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch adds functions to the Entries type which can be used for
filtering by id, either with `contains()` or `starts_with()`.
This is useful for the end-user functionality where the user specifies
the ID of an entry only partially.
The implementation still iterates over all entries. This could be
improved, of course, by implementing a `find`-like function on `Store`
directly. But for now, this is good enough.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch updates all dependencies but not "nom".
Done with `cargo upgrade --all` and manual editing.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch adds the "serde" feature to the "log" dependency, so we can
deserialize logging levels directly into "log" types.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch rewrites the logging config deserialization. It removes the
manual traversing of the config toml structure and replaces it with
types which implement `Deserialize`, which is way more convenient and
easy to read (and extend).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Prior to this change, the IdPathProvider implementation would be
responsible for exiting the process on insufficient / wrong arguments.
However, such error handling should be performed together with the
business logic and not in CLI-parsing related code.
This change introduces a clear separation: both parsing errors and
insufficient id path arguments can now be return from inside the
`get_ids`-method, and get passed up to the application logic to be
handled.
This change is reflected in all instances of IdPathProvider and their
surrounding code.
Signed-off-by: Leon Schuermann <leon.git@is.currently.online>
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
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>
The beta compiler reports duplicated input:
error: the item `IntoValues` is imported redundantly
--> lib/entry/libimagentrylink/src/internal.rs:398:13
|
36 | use self::iter::IntoValues;
| ---------------------- the item `IntoValues` is already imported here
...
398 | use internal::iter::IntoValues;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
so we fix this here.
Other imports were fixed as well.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
I'm not sure why the author added this in the first place, but I bet we
don't need this.
So remove code we do not need. Feel free to prove me wrong and revert
this patch.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
We iterate over full pathes to store entries here, which causes
`StoreId::new()` to error. But if we use the internal parsing helper
`StoreIdWithBase::from_full_path()` and then call `::into_storeid()` on
the resulting object, everything is fine.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
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>
Finally merging the redefine of the StoreId implementation, which allows
easier handling of StoreId objects.
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>
