I'm bringing this discussion here from a private email. I'm fairly certain this isn't going to irritate Terrence... right?
Lots of context left in place.
* Terrence Brannon [2004-12-17T18:31:16]
> Ricardo SIGNES writes:
> > * Terrence Brannon [2004-12-17T14:35:46]
> >> However, Querylet looks very attractive. One thing is that SQL can be
> >> used across databases and so I would not embed the DSN with the
> >> SQL... a more accurate approach would be a hierarchy of SQL such as is
> >> used DBIx::AnyDBD.
> >
> > I'm not sure I understand what you mean. Could you elaborate? I don't
> > like DSNs, but it's a simple way to make Querylet plain. At work, I
> > subclass Querylet to provide a "database" directive that builds the dbh.
>
> well, the SYNOPSIS had a DSN inside the Querylet text file... but
> given that certain SQL applies across databases, they should not be
> bound together this way.
I still don't understand, specifically "SQL applies across databases."
I've always assumed that almost the only Querlyet use case was something
like this:
The user has a database and wants to query it. He wants to do
something more complex than plain SQL, but doesn't want to learn how
to write anything other than simple declarations of how to deal with
the results.
I'd be surprised if the user ever needed to know the DSN was anything
but a magic word. In fact, our internal subclass of Querylet replaces
the "database:" directive so that a single magic word creates the
correct DSN. Sure, this means that sometimes the users need to know
that queries don't work the same on one database as on another. To
them, it's more magic.
> if you look at the way that DBIx::AnyDBD sets up a database-driven
> application, it uses subclassing with a default base class with
> "standard" sql and then subclasses such as MySQL, Pg, SQLite either
> have their own SQL or inherit from the base...
Right. A module that deals with a database gets n subclasses, with
names that relate them to DSNs. Do you mean, then, that a user would
write his query n times, one for each possible backend? Or that you'd
have n Querylet subclasses, each to write a new DSN string from some set
of parameters? The benefit of DBIx::AnyDBD seems to be in replacing
multiple database interactions so that the interface remains the same.
Querylet has a single interaction, basically. (connect, prepare,
execute, fetch)
> so what I am saying is that the DSN information should not be with the
> SQL because SQL is more generic than a DSN.
How would the abstraction be implemented and/or benefit real users?
> > There has been talk on (I think) [EMAIL PROTECTED] about giving
> > DBI and DBDs a way to build DSNs from parts, which I'll happily support
> > when it exists.
>
> yes, that was about my module DBIx::DBH
>
> >> Also, I dont think you are describing it correctly. I don't think it
> >> is a module for non-programmers. The syntax of add_column is rather
> >> advanced Perl.
> >
> > add column extended_price:
> > $value = $row->{quantity} * $row->{unit_price}
> >
> > I don't see much complexity there. Did you mean something else?
>
> well, that is not complicated for a Perl programmer, but others will
> be wondering about the "$" and "{" and "->"... Template Toolkit syntax
> (which I guess is Perl 6 syntax) might work better:
>
> value = row.quantity * row.unit_price
It would be possible to filter certain directives to replace things like
that, or to use TT2 itself to render the directive's contents into Perl.
I just think it's overkill. Users seem content to know that
$row->{COLUMN} is the magic incantation. It also makes it easy to hand
them more complicated recipes using less simple Perl. "Here, use this.
It's magic. It will fix broken datapoints."
It would actually be quite easy to subclass Querylet to do this; if
someone does it, I'd be interested to see it.
--
rjbs
pgpDOJBPfcG0t.pgp
Description: PGP signature
_______________________________________________ sw-design mailing list [EMAIL PROTECTED] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
