This patch adds a flag to the ContactStore::retrieve* functions so one
can override the ref data in the store for the retrieved entry.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Because we pull in libimagentryref here to create actual references to
the files we parse here, we need to rewrite the interface to be able to
pass the required information to the libimagentryref API.
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>
Rewrite to collect not so often internally. This removes one collect()
from the implementation. One is still there in the sorted_by() call,
though.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
The bug was that we compared the variable with itself, but one time to
lowercase and one time not, so it was always false.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
We create a sha1 over the path of the file and the Message-ID of the
mail itself.
The file name is not constant with mail files, because flags are encoded
in the filename. The path is also not constant with mail files, because
they can be moved between boxes.
This approach is not yet the best one, but better than before.
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>
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 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>
1.2 of lazy_static brings functionality to have no panics in the code,
which is what we try to have.
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>
...to report newly created entries, so that we can re-use these new
entries in the library-using code (for example for ID reporting).
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>
We have to move the `Email` type at the bottom of the DeserVcard type
because it contains a table and we must emit tables as last values when
de/serializing.
Maybe this will shoot us in the foot later, but only with TOML I guess.
We'll see. For now, this is good.
For that we need to update a dependency: vobject -> 0.5
We need to reverse the iterator for getting the _youngest_ entry here.
Also seems to fix the issue that imag-diary edit -d <date> did not work
properly.
