Pat Gunn (dachte) wrote,
Pat Gunn

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

  • Typing in Colours

    (Cross-posted to G+, but it's more of a definitive statement of views so it goes here too) A recent instance of 「Wasted Talent」: here I'm not…

  • Loyalty

    This is meant to address three ideas: Don't blame the victim If you care for me, you'd support me unconditionally Safe zonesAnd to be a topic in…

  • What Do We Owe Each Other?

    One of the central questions in political philosophy, or perhaps one of the most intuitive initial framings, is "what do we owe each other?". I…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded