emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sqlite3


From: Qiantan Hong
Subject: Re: sqlite3
Date: Thu, 16 Dec 2021 05:09:23 +0000

> elisp symbols are case insensitive as well, it’s a lisp-2, of the kind of 
> cl
Nah, Elisp fixed it. Also it’s unrelated to lisp-N

(eq 'test ‘TEST)
nil

> 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???
Looks like filename isn’t doing the correct thing, and single
file log has scaling issue. And now a correct and scalable solution
appears, so probably I should do it? Classic MITer don’t care
that much about implementation simplicity after all ;)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]