Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gnat (29)

gnat
  (email not shown publicly)

Journal of gnat (29)

Monday March 24, 2003
10:19 AM

Writing a DBD Module

[ #11199 ]
So I see a growing number of DBD modules that let you treat some data source (Excel, CSV, Google) as a database to be queried with SQL. Obviously things like joins won't make sense for every data source, but it's an intriguing idea.

Are there any existing docs on how to write a DBD module, using SQL::Statement? Or has everyone who's done it had to learn the ropes from scratch?

--Nat

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • DBI::DBD (Score:3, Informative)

    by Theory (10) on 2003.03.24 10:26 (#18247) Homepage Journal

    The canonical documentation for DBD writers is DBI::DBD [cpan.org].

    --David

  • When I started writing DBD::google, there was only one thing to go by: DBI::DBD, which gives a basic but servicable intro to writing a DBD. Since then, Takanori Kawai released DBD::Template, which provides a pretty good starting point, mostly (it seems) encapsulating the good advice from DBI::DBD.

    As far as SQL::Statement goes, I initially wrote DBD::google without it, but am rewriting it to subclass SQL::Parser and implement it's own feature set, which (SELECT-wise) is a superset of ANSI SQL, but in all

    --
    (darren)
  • For a secret project I worked on (which will eventually may DBD::Something) it was easier to write a new regex based SQL-like parser. SQL::Statement (a few months ago) was too strict, and didn't allow me to bend the rules.
    • Has anyone considered a Parse::RecDescent based SQL parser?

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • Has anyone considered a Parse::RecDescent based SQL parser?

        Take a look at SQL::Translator (on CPAN [cpan.org], also at http://sf.net/projects/sqlfairy/ [sf.net]), which is a set of modules designed to translate the CREATE syntax of one DB into another. Many of the parsers we currently have (MySQL, Sybase, Pg, Oracle) are based on Parse::RecDescent.

        --
        (darren)
      • It's not exactly what you mean, but Damian uses Parse::RecDescent to go the other way, turning English questions into valid SQL statements. If it's possible to go that way, surely parsing the much-more-regular-than-English SQL variant of any particular database has to be feasible.

        Random thought: would it make any sense to skip ahead a bit by poking around in the source of open source databases like MySQL & PostgreSQL and using their SQL parsing code as the basis for a general purpose SQL interpreter?

        --


        --
        DO NOT LEAVE IT IS NOT REAL.

        • Random thought: would it make any sense to skip ahead a bit by poking around in the source of open source databases like MySQL & PostgreSQL and using their SQL parsing code as the basis for a general purpose SQL interpreter?

          The SQL::Translator [cpan.org] folks have discussed (OK, I brought it up [sourceforge.net]) using the provided yacc grammars as the basis for the MySQL and Pg parsers, although none of us has done anything with it yet.

          Patches welcome... [sf.net]

          --
          (darren)
    • SQL::Statement (a few months ago) was too strict, and didn't allow me to bend the rules.

      I had a conversation about this very topic with Jeff Zucker a few weeks ago, because I had the same issues with SQL::Statement. He pointed me at SQL::Parser, upon which SQL::Statement is based, and which is much more flexible. You simply need to subclass SQL::Parser, and override the methods that aren't flexible enough for you.

      Also, the guts of SQL::Parser are regex-based, and Jeff seems pretty open to accepting id

      --
      (darren)