Holochain Forum

List all locally authored elements of a certain entry type that are up-to-date

Hi, I am trying to implement a zome call that lists all locally authored elements of a certain entry type (using hdk::chain::query) and excludes obsolete ones that have been updated or deleted (updates and deletes are only allowed by the original author, so local source chain should be sufficient). Has anyone done this before?

I was planning on using ChainQueryFilter::entry_type to do the filtering, but I looked at the structure of Header::Delete and it doesn’t contain an entry_type, so I expect that deletes won’t show up in my chain query.

Here is my attempt that I expect to fail:

fn list_my_messages() -> Result<Vec<Element>, MyError> {
    let message_elements =
        hdk::chain::query(ChainQueryFilter::new()
            .entry_type(/* message entry type omitted for brevity */)
            .include_entries(true))?;

    let obsolete_message_header_hashes: HashSet<_> = message_elements
        .iter()
        .filter_map(|element| match element.header() {
            Header::Update(Update {
                original_header_address,
                ..
            }) => Some(original_header_address.clone()),
            // oops! this match arm will never be reached, because Delete headers don't carry entry types.
            Header::Delete(Delete {
                deletes_address, ..
            }) => Some(deletes_address.clone()),
            _ => None,
        })
        .collect();

    Ok(message_elements
        .into_iter()
        .filter(|element| !obsolete_message_header_hashes.contains(element.header_address()))
        .collect())
}

I haven’t checked for certain that Deletes don’t show up in the chain query. So let me know if my assumption is just wrong.

1 Like

Hey @timotree3 , this is great to see, I love discussing design patterns. I don’t know of anyone that has attempted this, also because the way in which you interpret updates and deletes varies in different apps (maybe in my google docs clone app an update is not really making a document obsolete, just making a new version).

I think you are on the right track with everything you are saying. To get the deletes and still maintain this level of optimization, you can do a query of all the Delete headers, and add their entry hashes in obsolete_message_header_hashes, I think this would be the fastest way to do it. What do you think?

1 Like