Re: Gdbm module

[Bart Schaefer <schaefer@brasslantern.com>]

On Feb 21, 12:21pm, Sebastian Gniazdowski wrote:
}
} Do you think commiting "zgdbmclear" I've sent doesn't have sense?

I would prefer a bit more thought be put into the design.  There's no
particular problem with the implementation underneath, but:

The whole point of "ztie -d ..." and having the modules named with the
/db/ piece in the middle is so that a generic interface to multiple
database backends can be implemented.  "ztie" and "zuntie" happen to
be in db_gdbm.c for now because there is no other such module, but
the intention was that there would be a base "zsh/db" module of which
zsh/db/gdbm was one implementation.

In keeping with that, there shouldn't be commands named "zgdbm..." and
there should be no "zgdbm_tied" parameter -- there should instead be a
single array or hash in the (so far nonexistent) base module to return
all the ztie'd names, and if there are other ops needed than z(un)tie
then something like "zdb path ...", "zdb clear ...", etc. to give a
consistent front to whatever backend has been passed to "ztie -d".
(Or option names/letters instead of subcommands, to be more consistent
with most builtins, but you get the idea.)

This may mean that there are some ops that either we don't provide for
any backend because they're too specific to one, or that fail for some
backends.  E.g. "zdb path" doesn't make sense for a network-connected
database; maybe it returns a URL in that case, or we should consider
that the -f FILENAME argument of ztie is not sufficiently general, and
"zdb path" would just return back that argument of ztie.

None of this means we need to rush off to implement zsh/db/sqlite or
something, but we should be thinking about it when extending db/gdbm.