Re: sqlite3

[Jose E. Marchesi]

> "Jose E. Marchesi" <jemarch@gnu.org> writes:
>
>> gdbm may or may not be what you need in Emacs.
>> sqlite is not a replacement for gdbm.
>> recutils is not a replacement for sqlite.
>
>> It seems to me that any discussion in which it is raised the alternative
>> of using so disparaged systems such as gdbm, sqlite and recutils for
>> some particular purpose, is in serious need of some clarification on why
>> a database sytem is needed to begin with and the nature of the data to
>> be stored there.
>
> The idea is that people want a way to store key-value pairs quickly (as
> in, faster than a hash table serialized with `print').  Hence the idea
> to use (g)dbm.

If these are your requirements then I wouldn't recommend you to use
recutils, for several reasons.  Let me mention just a few.

First, recfiles are intended to be edited by hand as well as
programmatically.  This makes them sort of redundant, not very compact,
and also not the fastest format to parse and operate on.

Second, recutils supports relational and data integrity features that
may not be very useful in your case.  If as I suspect you plan to expose
a sort of data structure in Elisp to support key-value pairs (like what,
persistent a-lists backed by a dbm file?)  people using them will
undoubtly want to implement their own data integrity logic, or even
none.  You don't want to use anything that has its own ideas of what a
date looks like or how to compare them, for example.  This also applies
to sqlite and other relational database systems.

Third, recutils field keys are restricted to be something similar to a C
identifier, like in the record below from the GNU poke TODO file:

  Summary: unify `break' and `continue' in the same AST node
  Component: Compiler
  Kind: ENH
  Priority: 3
  Description:
  + The `break' and `continue' statements are similar enough to merit
  + using the same kind of AST node, which would require a discriminant
  + field (kind = break | continue).
  +
  + Likewise, there is some code duplication in the assembler which may be
  + optimized: pkl_asm_break_label_1 vs. pkl_asm_continue_label_1.
  Target: 2.0

it follows that if your pair keys can be arbitrary Elisp values then you
would be forced to use quite unnatural records like this for an a-list
'(("foo" (1 2 3) ("bar" (4 5 6)) (nil (0))):

  Key: "foo"
  Value: (1 2 3)

  Key: "bar"
  Value: (4 5 6)

  Key: nil
  Value: (0)

Fourth, you would also have problems with opaque lisp objects that don't
have a printed representation, in both keys and values.

Fifth, it seems to me that you don't need the notion of a "record"
(recutils) nor a relation (sqlite) in a key-value database.  If you come
with persistent a-lists (or similar) just pluck them into another list,
which may be itself be persistent and also backed by dbm.

And so on...  gdbm seems to provide exactly what you want, using
Lisp_Objects as keys and values.  I would just rejoice and use it :)