Re: sqlite3

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 16-a horo kaj 36:19 CET Qiantan Hong a 
écrit :
> > 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.

elisp symbols are case insensitive as well, it’s a lisp-2, of the kind of 
cl

also the canonical *standard* for naming elisp variables is a subset of 
what is allowed for filenames.  nobody seriously quotes their variable 
names or exceed the 72 columns limit with a single variable name and no 
indentation, so it might be okay to throw an error in edge cases, for 
portability… or maybe just a warning

plus, you could also hash the names, so you get only base 16, or 32, or 
something alike

> >> 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.

why are you complicating that much???