On Fri, Mar 01, 2002 at 08:53:33AM -0500, Aaron J Mackey wrote:
>
> There has been quite a bit of followup to my first posted ramblings; I've
> recieved lots of ideas, most of them very good. Fundamentally, though,
> there's the idea that this isn't really an "Inline" package, as in
> "(pre)compile this bit of native language in some other language-space and
> then make it available to my perl script".
Agreed. I've dropped [EMAIL PROTECTED] from the cc list.
> It's more of a "automatically
> build perl subroutines for me that make use of DBI". So maybe it's more
> of a DBIx::Inline::SQL or somesuch.
It doesn't need 'DBI' or 'Inline' in the name. Let's wait and see
what comes out of the discussions on the interface first.
> Ignore the bits about using C-like comments for subroutine definitions;
> that was a crackpot idea. I've had many other suggestions for syntax,
> like:
>
> SCALAR get_name ($id) { # or maybe even $get_name($id);
> SELECT name FROM users WHERE id = $id;
> }
>
> VOID set_name ($id, $name) { # or: set_name($id)
> UPDATE users SET name = $name WHERE id = $id;
> }
>
> LIST get_users () { # or: @get_users()
> SELECT name FROM users ORDER BY id;
> }
>
> etc.
The SCALAR/VOID/LIST seems not very useful for the effort.
I'd rather just use the calling context to imply scalar/list return.
> Thanks in advance for any commentary or advice.
It seems to me primary goal is to replace the 'scaffolding' or
infrastructure code that's needed to wrap up simple SQL statements,
and instead just specify a small, ideally zero, amount of declarative
information.
I'd start by ask people to suggest the kind of things that
they need to do in the simple wrappers that they already have.
And distinguish between things that the caller might also want to
control (like return rows as array or hash refs, or call prepare or
prepare_cached).
Also I think there may be good synergy here (ooops management speak [slap!])
with the new/planned DbTypeSubclass mechanism in the DBI (ala DBIx::AnyDBD).
A simple way to indicate generic and db-specific variants would be good.
FWIW, Damian's Getopt::Declare is a neat example of the benefits of the
declarative style:
http://search.cpan.org/doc/DCONWAY/Getopt-Declare-1.09/lib/Getopt/Declare.pm
Tim [rambling somewhat]
> -Aaron
>
> On Fri, 1 Mar 2002, Tim Bunce wrote:
>
> > On Thu, Feb 28, 2002 at 10:14:08PM -0800, Dean Arnold wrote:
> > > Just stumbled on this in c.l.p.modules, thought it deserves to be
> > > bounced around here...IMHO, this would be *very* gnarly!
> >
> > Bounced around on dbi-users, that is, not dbi-dev.
> > Also, I've CC'd the author.
> >
> > Tim.
> >
> > > ----- Original Message -----
> > > From: "Aaron J Mackey" <[EMAIL PROTECTED]>
> > > Newsgroups: comp.lang.perl.modules
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Tuesday, February 26, 2002 7:54 AM
> > > Subject: RFC: Inline::SQL
> > >
> > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
> --
> Aaron J Mackey
> Pearson Laboratory
> University of Virginia
> (434) 924-2821
> [EMAIL PROTECTED]
>
>
