Pat Gunn (dachte) wrote,
Pat Gunn
dachte

Hiding the Gatekeeper

Some time back, I blogged about this - developed further.

I really like SQL, and I really like the Unix userland. Neither are perfect, but they are excellent tools. The barriers between them are too high, and I've been working on ways to lower that every so often.

Unix strength: architected as if always exist in design decisions strand of thought: Can we make this a stream of bits sensibly? Answer: not always yes - pragmatic with a preference. Stream of bits model: generally great for gluing software together, power.

SQL strength: captures relational model for data well, particularly with relational calculus. Concurrency, transactionality also plusses, but exposed power of queries most important.

Issue: existing SQL tools: great for exploring a database (generally - mysql and oracle have tools that are bad for different reasons). These are less useful for CL use. Programming APIs to database provide tools to get information in more structured ways - the kind of data one can export to the shell is not good enough. How can we do better?

First draft (previously described):

  • dbgrep - pretends database is a directory hierarchy, treats second argument as a pseudopath, will search database for named string
  • Evaluation: a nice tool, but very limited. Read-only, clumsy, no real query power, single-purpose
Second draft - uses FUSE and DBI to expose database as a filesystem. This takes the conceptual model dbgrep gave and goes through the bother of exposing tables and tuples as files. Allows use of other tools to manipulate the database, parameters allow different delimiters for fields, "file" formats. Problem: exposes SQL data in a way that gives none of the power of SQL

Idea for third draft: incorprate the second draft under another virtual directory, but add a query directory whereby people make subdirectories, drop a SQL query of arbitrary complexity into a textfile, and a data directory is made with a full table as well as per-tuple file exports. For the content from the second draft, allow users to update the tuple files to change the data in the database, deleting, altering, possibly renaming, etc.

Making better abstractions on top of FUSE would be pretty much necessary for any real third draft - the FUSE API is powerful but very thorny.

Tags: programming
Subscribe

  • Testing functions in Perl

    (Nothing particularly profound or my-idea-centric here, and I was tempted to post it to my personal blog instead, but it's worth trying to learn…

  • Abstract strategies for abstraction

    There are a few purposes of abstraction in programming; one of them is to construct a uniform API that is independent of the backend that can work…

  • Statistical Software Components

    A few months ago I mentioned my big library of useful generic C/Perl functions (libpgunn). There are plenty of other general-purpose libraries out…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 2 comments