Re: Gdbm module

[Sebastian Gniazdowski <psprint2@xxxxxxxxxxxx>]

On Tue, Feb 21, 2017, at 09:25 AM, Bart Schaefer wrote:
> 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.

The dream of general ztie.. I saw how difficult it is when writing. Now
it seems totally possible, but when writing, it's other thing. The need
to move "bin_ztie" function, for example. Who would accept my patch that
would do that? (grumbling mode ended). And implementation difficulties,
first of all. Two modules, one has to detect the other one, route call.
Hm, this seems now quite easy, but when writing I saw the difficulties.
And what arises from that is mkfs-like design. Hands up who called
mkfs.ext2 or .ext4 instead of mkfs wrapper. And, who would accept Oracle
DBM module into Zsh? It's a nice DBM, free, unix-like (chances it nicely
fits just like GDBM, has its gdbm_fdesc() call). Then, this database has
it's own customs, for example access methods: btree, heap. Chances for
new special parameters and stuff.

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

Abstraction can go together with specific parts. A general ztie can be
maybe accomplished, but having "zgdbm_tied" is like a functionality:
"Someone passed me (P flag) a parameter, I can check if it's gdbm
frontend via zgdbm_tied array". Then we would have "zodbm_tied" for
Oracle DBM. Specific things at first level of use cases, then abstract
ones for possible many use cases.

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

Ok, such strive for abstraction is a good thing. One has to be in good
position in Zsh world to work on that comfortably, think freely about
Oracle DBM and its traits, then he can have success in discovering
symmetrical API.

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

I examined SQLite. There's a no-go – it doesn't return file descriptors
for database file and journal file. This is handy example now –
maintainers said: "file descriptors work on Unix, it would be not good
abstraction to return them".  Let's not do it, because it's not
abstract. Zsh is purely Unix world, file descriptor would be "fully
abstract", but no..  Here is full discussion:

http://sqlite.1065341.n5.nabble.com/how-to-get-file-handle-from-sqlite3-object-td28466.html

Then, as FDT_INTERNAL nor FDT_MODULE doesn't matter, SQLite might be
still possible. I looked at it, to do:

result=sqlarray["SELECT telephone FROM contacts WHERE id=1"]

And require single column to be selected, or concatenate columns, then
also append after \n when "...id=1 OR id=2". This doesn't match DBM
usage, though.

-- 
  Sebastian Gniazdowski
  psprint2@xxxxxxxxxxxx