We'll probably want to use a generic type here, but this is fine for a first pass

we could use generic type, but that generic type will be bubbled to higher structs. I cannot find a good way to avoid <P: PageManagerTrait> at Database and at the struct that uses Database. Any suggestion for that?

Technically we could encapsulate P by using a PageManager enum type containing each of the possible page manager implementations. This may be the right thing to do in order to hide the PageManager concept entirely from clients.

We don't really need a trait for this, unless you want to be able to run multiple implementations in parallel. I would just use a Cargo feature

@and-cb i just want to run one implementation at one time, and want an easy way to configure (benchmark program, reth). I am not sure with cargo flag, we have any better way than this?

#[cfg(feature = "mmap-backend")]
let db = Database::open(...)?;

#[cfg(feature = "bufferpool-backend")]  
let db = Database::open(...)?;

cargo test --features mmap-backend
cargo test --features bufferpool-backend

@BrianBland would the use of enum need a swithching like this for every common fn

    fn get(&self, page_id: PageId) -> Result<Page<'_>, PageError> {
        match self {
            Self::Mmap(manager) => manager.get(page_id),
            ...
        }
    }

The cargo test --features xyz part is correct; the #[cfg(feature = "xyz")] needs to be put above the PageManager implementations. Example:

// in src/page/manager.rs

#[cfg(feature = "mmap-backend")]
mod mmap;

#[cfg(feature = "bufferpool-backend")]
mod bufferpool;

// in src/page.rs

#[cfg(feature = "mmap-backend")]
pub use manager::mmap::PageManager;

#[cfg(feature = "bufferpool-backend")]
pub use manager::bufferpool::PageManager;

Now every code that does use crate::page::PageManager will get the one specified through --features

i think i will go with features from cargo. Thanks for suggestions