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 canonical documentation for DBD writers is DBI::DBD.
--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 other ways is extremely limited. Jeff Zucker (the SQL::Statement maintainer) tells me that the upcoming SQL::Statement version 1.006 will be even more amenable to subclassing that 1.005 is.
Re:secret project
jdavidb on 2003-03-24T19:50:36
Has anyone considered a Parse::RecDescent based SQL parser?
Re:secret project
dlc on 2003-03-25T13:03:32
Has anyone considered a Parse::RecDescent based SQL parser?Take a look at
SQL::Translator(on CPAN, also at http://sf.net/projects/sqlfairy/), 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.Re:secret project
babbage on 2003-03-26T04:34:26
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? Or would that be more trouble than it's worth? I suppose it depends on what you're trying to accomplish...
Re:secret project
dlc on 2003-03-26T14:14:16
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 folks have discussed (OK, I brought it up) using the provided yacc grammars as the basis for the MySQL and Pg parsers, although none of us has done anything with it yet.
Re:secret project
babbage on 2003-03-28T21:28:06
<diamond> "Patches welcome" is the lowest form of sarcasm. </diamond>Re:secret project
dlc on 2003-03-25T13:08:58
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 atSQL::Parser, upon whichSQL::Statementis based, and which is much more flexible. You simply need to subclassSQL::Parser, and override the methods that aren't flexible enough for you.Also, the guts of
SQL::Parserare regex-based, and Jeff seems pretty open to accepting ideas and patches, so you might want to talk to him about contributing your improvements / modifications.
