[Suggestion]: persist results to file

[fdncred]

Which fff frontend(s)?

Core or Rust crate

What problem are you trying to solve?

In nushell, I originally implemented idx export and idx import. It was kind of hacky so I removed it. It would be great to be able to index millions of files, save the index, exit the shell, come back in and restore the index and be able to search it normally. This isn't really a probelm with small groups of files because fff is so fast but when there are large groups of files, the ability to restore and index could be helpful.

Proposed solution

It would be nice to have some api that I could programmatically call from rust to dump the index to a file and another api call to restore from that index from file to searchable index. I keep getting asked for this. Here's the latest request nushell/nushell#18929

[gustav-fff]

[triage-bot] DUPLICATE: Duplicate of #642.

Same root cause: fff-core has no index serialization at all — nothing in crates/fff-core/src/file_picker.rs writes the path store / directory table / bigram index to disk, only frecency and query history are LMDB-backed (crates/fff-core/src/lib.rs:115). #642 asks for it from the Node SDK, this asks for it from the Rust crate; both need the same core dump/restore primitive first. Maintainer already answered there:

There is a way it is just not surfaced in the bun sdk. I had a hope to surface it at 0.10 but likely I won't be able to so this will only be abe to get to 0.11

Canonical: #642

Not something I touch — index serialization format plus staleness invalidation is a feature, not a fix. @dmtrKovalenko scopes it. Cross-link for context: nushell/nushell#18929

Honk-Honk 🪿

[dmtrKovalenko]

This is the active development. There is a way to use mmap file but no way to restore the index from saved file

[fdncred]

Great to know it's on the list. I was able to persist it to a sqlite.db and then load it back from sqlite.db. I thought it wasn't a super useful feature to have until I removed it and then people started complaining. LOL. I could probably just revert our removal but I'd rather have an api to do this type of thing so I'll probably wait to see if you come up with something. Thanks for the great tools!