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 a imag-calendar command which features only a "import"
command by now.
This can be used to import calendar entries (events) to imag.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch adds user documentation in for of a mdbook, using a travis
job for running the build of the book in CI to be sure it builds
properly.
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 pulls in the clippy fixes from Phil. From the request-pull:
-----8<-----
I finally got to fixing all of the Clippy warnings in the imag codebase.
`cargo test` passes, `cargo clippy` doesn't produce any warnings
or errors.
Some important notes:
- I didn't pay attention to the line length of the changes, so it may
have happened that some lines are now longer than 100 chars
- Except two commits the commit messages are formatted as follows:
* The first tag shows if the changes in the commit were
automatically applied by `cargo fix --clippy -Zunstable-options`.
Commits that were automatically applied may require closer review,
since I didn't check those by hand and the Clippy fix feature is
still unstable.
* The other tags specify the subcrate that is affected by the
commit. I created one commit for each subcrate, even when only one
file (most of the time the `main.rs` file) was changed.
- I created one commit, where I replace usages of `r#try!` with the
`?` operator, since `try!` is now officially deprecated.
- I created one commit, where I just allow Clippy lints. Either because
the fix would require much more work or knowledge of the codebase or
because it was a FP.
This was pretty much work, but it helped detecting a few bugs in Clippy,
where I was already able to open 3 or 4 PRs. So win-win I guess.
[...] we got a net LoC decrease.
----->8-----
Matthias Beyer
flip1995