Handling cases where the key depends on a multi-value field

[Curstantine]

I'm having trouble with understanding how to implement a CollectionMapReduce that depends on a multi-valued field.
According to my understanding, you can pass a tuple as a key to handle cases where you'd want to filter by more than one field.

However, given a sturct like below, how would you go about implementing a map-reduce that accepts a tuple of (name, artist_id)?

struct Release {
    name: String,
    artist_ids: Option<Vec<u64>>,
}

My current implementation uses the Mapping::List variant to emit the same document with all the different artist ids, but it panics with: error from view: error serializing view keys key error: unexpected end of file. And I think there's a better way to do this.

pub type ReleaseByNameAndArtistData = (String, Option<u64>);

#[derive(Debug, Clone, View, ViewSchema)]
#[view(collection = Release, key = ReleaseByNameAndArtistData, value = u64)]
pub struct ReleaseByNameAndArtist;

impl CollectionMapReduce for ReleaseByNameAndArtist {
    fn map<'doc>(&self, document: CollectionDocument<Release>) -> ViewMapResult<'doc, Self::View> {
        let x = document.contents;

        match &x.artists {
            Some(artists) => {
                let mut maps = Vec::<Map<ReleaseByNameAndArtistData, u64>>::with_capacity(artists.len());
                let header = Header::try_from(document.header)?;

                for artist in artists {
                    let key_tuple: ReleaseByNameAndArtistData = (x.name.clone(), Some(artist.id));
                    maps.push(Map::new(header.clone(), key_tuple, 1));
                }

                Ok(Mappings::List(maps))
            }
            None => document.header.emit_key_and_value((x.name, None), 1),
        }
    }
}

Some guidance would really help, thank you!

Edit:
I think I found the issue. Option::None isn't allowed in the derived Key trait.

[ecton]

Sorry for the delay in getting back to you. Your edit looks like you found the issue -- BonsaiDb 0.4 had a documented limitation around storing Options in Tuples due to how it was being encoded. I had addressed this in the main branch at some point in the past year, but I had been lagging behind on getting a new release put together.

I've released v0.5.0 a few minutes ago which has the new composite key encoding support, but it also has a new derive macro allowing Key to be derived on custom structs and enums.