Data file with 0 buckets (header only) just returns "invalid bucket count"

[MarkusTeufelberger]

According to the README "The Data File contains the Header followed by zero or more variable-length Value Records and Spill Records."

However when I manually build a header file, run rekey (with a count of 0) and then verify, verify doesn't like the result at all.

[vinniefalco]

Hmm... an interesting corner case that I have not thought of. The key file has to have one empty bucket upon creation. What do you suggest as a fix?

[MarkusTeufelberger]

I think the idea of having a database file with 0 entries is a valid potential use case.

Potential solutions off the top of my head could be a special "Nil" entry for empty databases that can get removed on the first insert (which would hurt the "append-only" paradigm), having a default, static "0-th" entry that can always be queried even on empty databases (kinda like a zero register that always returns zero or /dev/null) or just disallowing that use case and requiring at least one value record to exist. Another solution would be to have an "empty" or "uninitialized" flag in the key file header, but this would make the code more complex elsewhere (since it is not enough to check for >0 buckets).
As far as I understand it, the .key file is append only as well, so a "dummy bucket" would also be not really desirable.
Another solution might be to only create (or access) key files if there is already at least one entry in the dat file - similar to log files which also don't always exist.
Last but not least, 0 could be a valid number of keys in a bucket.

It's just something that came up when I tried to start to test the insert command that I wrote and I suddenly couldn't even do the simplest case of inserting an entry into an empty database. I don't really have strong opinions either way.

[MarkusTeufelberger]

Since NuDB is now 1.0.0, what did you decide for resolving this issue? Empty databases have their use after all and currently either the spec or the code is wrong in dealing with this.

[vinniefalco]

Looks like this is something that needs to be fixed in a future version!