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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Writing a DBD Module 9 Comments More | Login | Reply /

 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)
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.