Re: sqlite3

[Qiantan Hong]

> Why don’t you hack multisession so that it includes a such layer, between 
> the current highest-level interface, the choice between sqlite/files? even 
> before that, you could add your incremental-log-store to them, and also, 
> why not, at least for benchmark sake, a store where one file contains 
> everything such as custom.el
I realized some serious problem about file-per-key method, I see Lars
also use it so guess it will help to discuss.
Basically, printing the key as file name does not guarantee distinguishing
the key
1. Even if one escape the key, the printed representation may be larger
  than 255 bytes, or 8bytes in FAT32 (idk if any one still use it). In such 
case,
  two different key may give the same filename because the prefix is
  the same
2. What’s worse, some FS are case insensitive.

>> AFAIK the general way to avoid these issues is to store/log not the
>> "data-diff" but the higher-level operation that caused this diff.
>> E.g. log something like "add X to tree" instead of recording which nodes
>> in the tree were modified in which way.  This way, the presence or
>> absence of cycles in the representation of the tree doesn't come into
>> the picture at all.
> 
> Looks like Qiantan’s implementation of incremental log-like store.
I think maybe this hinted us that we can get the best out of both
by using filename as a “bucket splitter”, and have an incremental
log store in each file? Then we can be loose about file name normalization
because it’s just an optimization (and make it more readable).
It’s also almost as easy for people to explore as one-file-per-key.