No real code yet, just some example usage; I'm "trolling" for feedback and
concerns before I really get into it:
#!/usr/bin/perl -Tw
use Inline;
my ($host, $user, $pw, $db) = qw(localhost me youwish mydb);
Inline->bind(SQL => DATA,
DBD => 'mysql',
HOST => $host,
USER => $user,
PW => $pw,
DB => $db);
my $id = get_user_id('phooey');
set_user_name($id, 'phoooey');
my @users = get_users();
__DATA__
/* get_user_id($name) */
select id
from users
where name like $name
/* set_user_name($id, $name) */
update users
set name = $name
where id = $id
/* get_users() */
select id, name
from users
order by name asc
To flesh out the ideas, here are some of my own comments:
1. We need to specify connection metadata (DBD driver to use, and
connection parameters: we can specify those at import time (use Inline SQL
=> DATA, HOST => 'myhost', etc), or at run time via Inline->bind(), or in
a metadata section of the __DATA__ stream (not sure I like that so much).
2. Inline::SQL would parse the __DATA__ stream looking for function
prototypes between /* */ C comments (suggestions for other
syntax/delimiters welcome), followed by sql statements that make use of
the variable names (i.e. none of this ?, ?, ? stuff); I think this yields
more readable Perl code [rather than $sth->prepare($name, $id), we have
set_name($id, $name) ].
3. Inline::SQL would use DBI methods to handle the requests (with
prepare_cached and whatnot on transmogrified SQL statements
containing appropriate ? placeholders).
4. We'd use wantarray() to figure out whether we need to return an array
of rows from a select statement, or whether to return a single row.
Drawbacks of Inline::SQL :
1. Don't see a clean way to do the usual prepare(), while(fetch()) looping
you'd normally do with DBI; Inline::SQL functions will always return all
of the results (potentially very large sets).
Others I'm sure; only just beginning to think about it.
Feedback very welcome, as always.
-Aaron
