DBD::google allows you to use Google as a datasource; google can be queried using SQL *SELECT* statements, and iterated over using standard DBI conventions.
For the most part, use "DBD::google" like you use any other DBD, except instead of going through the trouble of building and installing (or buying!) database software, and employing a DBA to manage your data, you can take advantage of Google's ability to do this for you.
For the most part, use "DBD::google" like you use any other DBD, except instead of going through the trouble of building and installing (or buying!) database software, and employing a DBA to manage your data, you can take advantage of Google's ability to do this for you. Think of it as outsourcing your DBA, if you like.
Connection Information
The connection string should look like: "dbi:google:" (DBI requires the trailing ":").
Your Google API key should be specified in the username portion (the password is currently ignored; do whatever you want with it, but be warned that I might put that field to use some day):
my $dbh = DBI->connect("dbi:google:", "my key", undef, %opts);
Alternatively, you can specify a filename in the user portion; the first line of that file will be treated as the key: my $dbh =DBI->connect("dbi:google:", File::Spec->catfile($ENV{HOME}, ".googlekey"))In addition to the standard DBI options, the fourth argument to connect can also include the following "DBD::google" specific options, the full details of each of which can be found in the Net::Google manpage:
ie Input Encoding. String, e.g., "utf-8".
oe Output Encoding. String, e.g., "utf-8".
safe Should safe mode be on. Boolean.
filter Should results be filtered. Boolean.
lr Something to do with language. Arrayref. debug Should "Net::Google" be put into debug mode or not? Boolean.Supported SQL Syntax and Random Notes Thereon
The only supported SQL statement type is the *SELECT* statement. Since there is no real "table" involved, I've created a hypothetical table, called *google*; this table has one queryable field, *q* (just like the public web-based interface). The available columns are currently dictated by the data available from the underlying transport, which is the Google SOAP API (see http://www.google.com/apis), as implemented by Aaron Straup Cope's "Net::Google" module.
The basic SQL syntax supported looks like:
SELECT @fields FROM google WHERE q = '$query'
There is also an optional LIMIT clause, the syntax of which is similar to that of MySQL's LIMIT clause; it takes a pair: offset from 0, number of results. In practice, Google returns 10 results at a time by default, so specifying a high LIMIT clause at the beginning might make sense for many queries.
The list of available fields in the *google* table includes:
title Returns the title of the result, as a string. URL Returns the URL of the result, as a (non-HTML encoded!) string. snippet Returns a snippet of the result. cachedSize Returns a string indicating the size of the cached version of the document.directoryTitle Returns a string.
summary Returns a summary of the result.
hostName Returns the hostname of the result.
directoryCategory
Returns the directory category of the result.
The column specifications can include aliases:
SELECT directoryCategory as DC FROM google WHERE...
Finally, "DBD::google" supports functions:
SELECT title, html_encode(url) FROM google WHERE q = '$stuff'
There are several available functions available by default:
uri_escape This comes from the "URI::Escape" module.
html_escape This wraps around "HTML::Entities::encode_entities". html_strip This removes HTML from a field. Some fields, such as title, summary, and snippet, have the query terms highlighted with tags by Google; this function can be used to undo that damage.Finally, "DBD::google" also supports arbitrary functions, specified using a fully qualified Perl package identifier:
SELECT title, Digest::MD5::md5_hex(title) FROM google WHERE ...
Functions and aliases can be combined:
SELECT html_strip(snippet) as stripped_snippet FROM google...
Unsupported SQL includes ORDER BY clauses (Google does this, and provides no interface to modify it), HAVING clauses, JOINs of any type (there's only 1 "table", after all), sub-SELECTS (I can't even imagine of what use they would be here), and, actually, anything not explicitly mentioned above.
Find us on Google+
