ch7: actionkv v2.0 does not resolve the problem in actionkv v1.0

[yamoridon]

Section 7.7.11 points out a problem of actionkv v1 is that it has long start up time and describes a way to shorten it by storing the index itself on the database. But actionkv v2 still reads all of the database file and rebuilds the index. Thus the problem of actionkv v1 is not resolved. Considring the discussion of this section, I think it should be resolved.

[brunojppb]

Hey folks, I've just been through Chapter 7 and I think @yamoridon is correct. If we look at the source here, the lib.rs implementation still rebuilds the index when we call load. Here is how the source looks like:

Load call site

code/ch7/ch7-actionkv2/src/akv_disk.rs

Line 44 in 19c4349

a.load().expect("unable to load data");

Inserting in the index

code/ch7/ch7-actionkv2/src/lib.rs

Line 100 in 19c4349

self.index.insert(kv.key, current_position);

I was wondering how @timClicks would approach this part.
Appreciate any feedback on that.

[timClicks]

I wondered when this would be pointed out. At one point I did implement a fix for this, but I believe that I pulled it out to simplify the v2 code example.

[anBertoli]

@timClicks do you accept PRs to fix this type of issues? I would be happy to help.

[ladislaff93]

Why does the store_index_on_disk removing the self.index ? a.index = std::collections::HashMap::new(); I dont get it

[xitep]

• i think a less confusing approach to demonstrating the utility of de/serialization would be to store the index (as a kind of cache) in a separate file (this would utilize the the material from section 7.2.) appending the index (for each modification) to the database file itself is wasteful.
• to demonstrate some more work around HashMaps in this section, maybe extending the ActionKV#load method to prune the index of empty value entries (as created the by the "delete" command) could serve as a case study.

[ladislaff93]

• i think a less confusing approach to demonstrating the utility of de/serialization would be to store the index (as a kind of cache) in a separate file (this would utilize the the material from section 7.2.) appending the index (for each modification) to the database file itself is wasteful.
• to demonstrate some more work around HashMaps in this section, maybe extending the ActionKV#load method to prune the index of empty value entries (as created the by the "delete" command) could serve as a case study.

That is exactly the way I did it. I made index and data files and index is rebuilded from index file