Ricardo SIGNES
2004-12-18 01:01:40 UTC
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]
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.
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)
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
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.
certain this isn't going to irritate Terrence... right?
Lots of context left in place.
* Terrence Brannon [2004-12-17T18:31:16]
* Terrence Brannon [2004-12-17T14:35:46]
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... butHowever, 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'tused 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.
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.
given that certain SQL applies across databases, they should not be
bound together this way.
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, withapplication, 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...
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?SQL because SQL is more generic than a DSN.
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::DBHwhen it exists.
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.
$value = $row->{quantity} * $row->{unit_price}is a module for non-programmers. The syntax of add_column is rather
advanced Perl.
I don't see much complexity there. Did you mean something else?
be wondering about the "$" and "{" and "->"... Template Toolkit syntax
value = row.quantity * row.unit_price
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
rjbs