zsh/db oddities

[Bart Schaefer <schaefer@brasslantern.com>]

The only example so far is of course zsh/db/gdbm.

Open a database as a global and assign something to it:

% zmodload zsh/db/gdbm
ztie -d db/gdbm -f sample.gdbm sampledb
% sampledb[GLOBAL]=global
% cksum sample.gdbm
3454148649 16384 sample.gdbm

Now start messing with the declaration in a function:

% () {
cksum sample.gdbm
local sampledb
typeset +m sampledb
cksum sample.gdbm
sampledb[INFUNC]=set
cksum sample.gdbm
print $sampledb[INFUNC]
}
3454148649 16384 sample.gdbm
association local sampledb
2087515864 16384 sample.gdbm
2669724292 16384 sample.gdbm
set

As soon as the tied parameter is declared local, the file has been
written, erasing all the existing values.  This seems undesirable?
Returning to the top level:

% cksum sample.gdbm
1634404396 16384 sample.gdbm
% typeset -p sampledb
typeset -A sampledb=( [GLOBAL]=global )

The file has been written again and the original state is back.

If instead you zuntie the local:

% () {
local sampledb
sampledb[LOCAL]=local
zuntie sampledb
}
% typeset -p sampledb
typeset: no such variable: sampledb

Untying the local destroys the global, too, and leaves the file as the
local wrote it.

% ztie -d db/gdbm -f sample.gdbm sampledb
% typeset -p sampledb
typeset -A sampledb=( [LOCAL]=local )

I think the correct thing might be to prohibit changing the scope,
similar to what happens when an attempt is made to remove the readonly
attribute?

% ztie -r -d db/gdbm -f sample.gdbm sampledb
% () {
local -A +r sampledb
}
(anon):local:1: sampledb: can't change type of a special parameter

Re-ztie-ing the database file while it is still tied, is already
handled as an error.