2017-09-15 11:07:49 +00:00
|
|
|
//
|
|
|
|
// imag - the personal information management suite for the commandline
|
2019-01-03 01:32:07 +00:00
|
|
|
// Copyright (C) 2015-2019 Matthias Beyer <mail@beyermatthias.de> and contributors
|
2017-09-15 11:07:49 +00:00
|
|
|
//
|
|
|
|
// This library is free software; you can redistribute it and/or
|
|
|
|
// modify it under the terms of the GNU Lesser General Public
|
|
|
|
// License as published by the Free Software Foundation; version
|
|
|
|
// 2.1 of the License.
|
|
|
|
//
|
|
|
|
// This library is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
// Lesser General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU Lesser General Public
|
|
|
|
// License along with this library; if not, write to the Free Software
|
|
|
|
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
//
|
|
|
|
|
2018-05-01 14:25:22 +00:00
|
|
|
macro_rules! mk_iterator_mod {
|
2017-09-15 11:17:12 +00:00
|
|
|
{
|
|
|
|
modname = $modname:ident,
|
|
|
|
itername = $itername:ident,
|
|
|
|
iteryield = $yield:ty,
|
|
|
|
extname = $extname:ident,
|
|
|
|
extfnname = $extfnname:ident,
|
|
|
|
fun = $fun:expr
|
2017-11-25 15:50:39 +00:00
|
|
|
} => {
|
|
|
|
pub mod $modname {
|
2018-05-01 14:25:22 +00:00
|
|
|
use storeid::StoreId;
|
|
|
|
#[allow(unused_imports)]
|
|
|
|
use store::FileLockEntry;
|
|
|
|
use store::Store;
|
2018-10-30 17:40:50 +00:00
|
|
|
use failure::Fallible as Result;
|
2017-11-25 15:50:39 +00:00
|
|
|
|
2018-10-30 17:40:50 +00:00
|
|
|
pub struct $itername<'a>(Box<Iterator<Item = Result<StoreId>> + 'a>, &'a Store);
|
2017-11-25 15:50:39 +00:00
|
|
|
|
2018-10-30 17:40:50 +00:00
|
|
|
impl<'a> $itername<'a>
|
2017-11-25 15:10:07 +00:00
|
|
|
{
|
2018-10-30 17:40:50 +00:00
|
|
|
pub fn new(inner: Box<Iterator<Item = Result<StoreId>> + 'a>, store: &'a Store) -> Self {
|
2018-05-01 14:25:22 +00:00
|
|
|
$itername(inner, store)
|
2017-11-25 15:50:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-30 17:40:50 +00:00
|
|
|
impl<'a> Iterator for $itername<'a>
|
2018-05-01 14:25:22 +00:00
|
|
|
{
|
2018-10-30 17:40:50 +00:00
|
|
|
type Item = Result<$yield>;
|
2018-05-01 14:25:22 +00:00
|
|
|
|
|
|
|
fn next(&mut self) -> Option<Self::Item> {
|
2018-10-30 17:40:50 +00:00
|
|
|
self.0.next().map(|id| $fun(id?, self.1))
|
2017-09-15 11:17:12 +00:00
|
|
|
}
|
|
|
|
}
|
2017-11-25 15:10:07 +00:00
|
|
|
|
2018-10-30 17:40:50 +00:00
|
|
|
pub trait $extname<'a> {
|
|
|
|
fn $extfnname(self, store: &'a Store) -> $itername<'a>;
|
2018-05-01 14:25:22 +00:00
|
|
|
}
|
2017-11-25 15:50:39 +00:00
|
|
|
|
2018-10-30 17:40:50 +00:00
|
|
|
impl<'a, I> $extname<'a> for I
|
|
|
|
where I: Iterator<Item = Result<StoreId>> + 'a
|
2018-05-01 14:25:22 +00:00
|
|
|
{
|
2018-10-30 17:40:50 +00:00
|
|
|
fn $extfnname(self, store: &'a Store) -> $itername<'a> {
|
2018-05-01 14:25:22 +00:00
|
|
|
$itername(Box::new(self), store)
|
|
|
|
}
|
2017-11-25 15:50:39 +00:00
|
|
|
}
|
2017-09-15 11:07:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-15 11:17:12 +00:00
|
|
|
mk_iterator_mod! {
|
|
|
|
modname = create,
|
|
|
|
itername = StoreCreateIterator,
|
|
|
|
iteryield = FileLockEntry<'a>,
|
|
|
|
extname = StoreIdCreateIteratorExtension,
|
|
|
|
extfnname = into_create_iter,
|
2018-05-01 14:25:22 +00:00
|
|
|
fun = |id: StoreId, store: &'a Store| store.create(id)
|
2017-09-15 11:07:49 +00:00
|
|
|
}
|
|
|
|
|
2017-09-15 11:17:12 +00:00
|
|
|
mk_iterator_mod! {
|
|
|
|
modname = delete,
|
|
|
|
itername = StoreDeleteIterator,
|
|
|
|
iteryield = (),
|
|
|
|
extname = StoreIdDeleteIteratorExtension,
|
|
|
|
extfnname = into_delete_iter,
|
2018-05-01 14:25:22 +00:00
|
|
|
fun = |id: StoreId, store: &'a Store| store.delete(id)
|
2017-09-15 11:07:49 +00:00
|
|
|
}
|
|
|
|
|
2017-09-15 11:17:12 +00:00
|
|
|
mk_iterator_mod! {
|
|
|
|
modname = get,
|
|
|
|
itername = StoreGetIterator,
|
|
|
|
iteryield = Option<FileLockEntry<'a>>,
|
|
|
|
extname = StoreIdGetIteratorExtension,
|
|
|
|
extfnname = into_get_iter,
|
2018-05-01 14:25:22 +00:00
|
|
|
fun = |id: StoreId, store: &'a Store| store.get(id)
|
2017-09-15 11:17:12 +00:00
|
|
|
}
|
2017-09-15 11:07:49 +00:00
|
|
|
|
2017-09-15 11:17:12 +00:00
|
|
|
mk_iterator_mod! {
|
|
|
|
modname = retrieve,
|
|
|
|
itername = StoreRetrieveIterator,
|
|
|
|
iteryield = FileLockEntry<'a>,
|
|
|
|
extname = StoreIdRetrieveIteratorExtension,
|
|
|
|
extfnname = into_retrieve_iter,
|
2018-05-01 14:25:22 +00:00
|
|
|
fun = |id: StoreId, store: &'a Store| store.retrieve(id)
|
2017-11-25 15:50:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(test)]
|
2017-12-25 18:23:39 +00:00
|
|
|
#[allow(dead_code)]
|
2017-11-25 15:50:39 +00:00
|
|
|
mod compile_test {
|
|
|
|
|
|
|
|
// This module contains code to check whether this actually compiles the way we would like it to
|
|
|
|
// compile
|
|
|
|
|
|
|
|
use store::Store;
|
|
|
|
use storeid::StoreId;
|
|
|
|
|
|
|
|
fn store() -> Store {
|
2018-03-16 23:06:13 +00:00
|
|
|
unimplemented!("Not implemented because in compile-test")
|
2017-11-25 15:50:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fn test_compile_get() {
|
|
|
|
let store = store();
|
|
|
|
let _ = store
|
|
|
|
.entries()
|
|
|
|
.unwrap()
|
2018-01-28 20:24:02 +00:00
|
|
|
.into_get_iter();
|
2017-11-25 15:50:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fn test_compile_get_result() {
|
|
|
|
fn to_result(e: StoreId) -> Result<StoreId, ()> {
|
|
|
|
Ok(e)
|
|
|
|
}
|
|
|
|
|
|
|
|
let store = store();
|
|
|
|
let _ = store
|
|
|
|
.entries()
|
|
|
|
.unwrap()
|
2018-01-28 20:24:02 +00:00
|
|
|
.into_get_iter();
|
2017-11-25 15:50:39 +00:00
|
|
|
}
|
2017-09-15 11:07:49 +00:00
|
|
|
}
|
|
|
|
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
use storeid::StoreId;
|
|
|
|
use self::delete::StoreDeleteIterator;
|
|
|
|
use self::get::StoreGetIterator;
|
|
|
|
use self::retrieve::StoreRetrieveIterator;
|
|
|
|
use file_abstraction::iter::PathIterator;
|
|
|
|
use store::Store;
|
2018-10-30 17:40:50 +00:00
|
|
|
use failure::Fallible as Result;
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
|
|
|
|
/// Iterator for iterating over all (or a subset of all) entries
|
|
|
|
///
|
|
|
|
/// 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.
|
|
|
|
///
|
|
|
|
/// As the (for the filesystem backend underlying) `walkdir::WalkDir` type is not as nice as it
|
|
|
|
/// could be, iterating over two subdirectories with one iterator is not possible. Thus, iterators
|
|
|
|
/// for two collections in the store should be build like this (untested):
|
|
|
|
///
|
|
|
|
/// ```ignore
|
|
|
|
/// store
|
|
|
|
/// .entries()?
|
|
|
|
/// .in_collection("foo")
|
|
|
|
/// .chain(store.entries()?.in_collection("bar"))
|
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// Functionality to exclude subdirectories is not possible with the current implementation and has
|
|
|
|
/// to be done during iteration, with filtering (as usual).
|
2018-11-28 01:14:39 +00:00
|
|
|
pub struct Entries<'a>(PathIterator<'a>, &'a Store);
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
|
|
|
|
impl<'a> Entries<'a> {
|
|
|
|
|
2018-11-28 01:14:39 +00:00
|
|
|
pub(crate) fn new(pi: PathIterator<'a>, store: &'a Store) -> Self {
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
Entries(pi, store)
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn in_collection(self, c: &str) -> Self {
|
|
|
|
Entries(self.0.in_collection(c), self.1)
|
|
|
|
}
|
|
|
|
|
2018-11-28 01:14:39 +00:00
|
|
|
// TODO: Remove or fix me
|
|
|
|
//pub fn without_store(self) -> StoreIdIterator {
|
|
|
|
// StoreIdIterator::new(Box::new(self.0.map(|r| r.map(|id| id.without_base()))))
|
|
|
|
//}
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
|
|
|
|
/// Transform the iterator into a StoreDeleteIterator
|
|
|
|
///
|
|
|
|
/// This immitates the API from `libimagstore::iter`.
|
2018-10-30 17:40:50 +00:00
|
|
|
pub fn into_delete_iter(self) -> StoreDeleteIterator<'a> {
|
2018-11-28 01:14:39 +00:00
|
|
|
StoreDeleteIterator::new(Box::new(self.0.map(|r| r.map(|id| id.without_base()))), self.1)
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Transform the iterator into a StoreGetIterator
|
|
|
|
///
|
|
|
|
/// This immitates the API from `libimagstore::iter`.
|
2018-10-30 17:40:50 +00:00
|
|
|
pub fn into_get_iter(self) -> StoreGetIterator<'a> {
|
2018-11-28 01:14:39 +00:00
|
|
|
StoreGetIterator::new(Box::new(self.0.map(|r| r.map(|id| id.without_base()))), self.1)
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Transform the iterator into a StoreRetrieveIterator
|
|
|
|
///
|
|
|
|
/// This immitates the API from `libimagstore::iter`.
|
2018-10-30 17:40:50 +00:00
|
|
|
pub fn into_retrieve_iter(self) -> StoreRetrieveIterator<'a> {
|
2018-11-28 01:14:39 +00:00
|
|
|
StoreRetrieveIterator::new(Box::new(self.0.map(|r| r.map(|id| id.without_base()))), self.1)
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Iterator for Entries<'a> {
|
|
|
|
type Item = Result<StoreId>;
|
|
|
|
|
|
|
|
fn next(&mut self) -> Option<Self::Item> {
|
2018-11-28 01:14:39 +00:00
|
|
|
self.0.next().map(|r| r.map(|id| id.without_base()))
|
Optimize the Store::entries() interface
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>
2018-06-06 22:29:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-15 17:26:57 +00:00
|
|
|
#[cfg(test)]
|
|
|
|
mod tests {
|
|
|
|
extern crate env_logger;
|
|
|
|
|
|
|
|
use std::path::PathBuf;
|
|
|
|
use std::sync::Arc;
|
|
|
|
|
|
|
|
fn setup_logging() {
|
|
|
|
let _ = env_logger::try_init();
|
|
|
|
}
|
|
|
|
|
|
|
|
use store::Store;
|
|
|
|
use storeid::StoreId;
|
|
|
|
use file_abstraction::InMemoryFileAbstraction;
|
|
|
|
use libimagutil::variants::generate_variants;
|
|
|
|
|
|
|
|
pub fn get_store() -> Store {
|
|
|
|
let backend = Arc::new(InMemoryFileAbstraction::default());
|
|
|
|
Store::new_with_backend(PathBuf::from("/"), &None, backend).unwrap()
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_entries_iterator_in_collection() {
|
|
|
|
setup_logging();
|
|
|
|
let store = get_store();
|
|
|
|
|
|
|
|
let ids = {
|
|
|
|
let base = String::from("entry");
|
|
|
|
let variants = vec!["coll_1", "coll_2", "coll_3"];
|
|
|
|
let modifier = |base: &String, v: &&str| {
|
2018-11-28 01:14:39 +00:00
|
|
|
StoreId::new(PathBuf::from(format!("{}/{}", *v, base))).unwrap()
|
2019-02-15 17:26:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
generate_variants(&base, variants.iter(), &modifier)
|
|
|
|
};
|
|
|
|
|
|
|
|
for id in ids {
|
|
|
|
let _ = store.retrieve(id).unwrap();
|
|
|
|
}
|
|
|
|
|
|
|
|
let succeeded = store.entries()
|
|
|
|
.unwrap()
|
|
|
|
.in_collection("coll_3")
|
|
|
|
.map(|id| { debug!("Processing id = {:?}", id); id })
|
|
|
|
.all(|id| id.unwrap().is_in_collection(&["coll_3"]));
|
|
|
|
|
|
|
|
assert!(succeeded, "not all entries in iterator are from coll_3 collection");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|