On Mon, 4 Mar 2002, Tim Bunce wrote:
> 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.
Yep. And Damian's Getopt::Declare is actually a great example of what I'm
proposing. I would note that Getopt::Declare includes both
explicit declarations of input, as well as implicit definitions of the
"output" (my SCALAR/VOID/LIST nomenclature, that could be extended to also
include HASH, ARRAYREFS, HASHREFS to signal what kind of resultset is
expected):
# in addition to my previous examples for SCALAR, VOID and LIST contexts
# that only return one row of data:
# returns a hash of (field name => data) values
HASH get_properties($id) {
select * from properties where user_id = $id;
}
# returns an array of arrayrefs for each row in the resultset:
ARRAYREFS get_users() {
select id, name from users;
}
# now a combination of the above:
HASHREFS get_users_properties() {
select users.id, users.name, properties.*
from users inner join properties on users.user_id = properties.user_id
}
> 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).
I'd propose something like:
CACHE ARRAYREFS get_users() {
select id, name from users;
}
Akin to C's static/const/register modifiers.
regarding some people's desires to use database-bound stored procedures:
go right ahead, I'm not stopping you:
VOID delete_user($id) {
execute delete_user($id);
}
But since procedural SQL is handled so differently by each database
vendor, I don't think I want to try to handle CREATE FUNCTION syntax
parsing myself (does DBI have a hook into these? I didn't think so ...)
-Aaron
