-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Actually, DBI already mandates support for the "?" in all DBDs, as
> far as I know, and some of them have to resort to search-n-replace in
> the SQL string at execute() time since the database doesn't have
> native support.
Or search-n-replace at prepare time for those that support native
placeholders (none that I know of actually use '?', it's $1 or :foo).
> I see bind parameters to be exactly the same as function arguments,
> conceptually speaking. Your $1, $2 etc is like using @_ subscripts.
>
> I can also think of several ways that named is easier.
Sure, I don't have a problem with the :foo form, I was just saying
that for short examples, the '?' format is simpler:
$sth->execute(101);
vs.
$sth->execute( { "myfirstarg", 101 });
or
$sth->bind_param("myfirstarg", 101 ...);
$sth->execute();
> Then there's the time you want to use the same bind variable in
> several places in the same query. With the ? approach, you have to
> bind it multiple times; being limited in that way doesn't seem right.
Sure, that's why DBI should encourage drivers to support the other two
ways as well. Having said all of the above, if I had to pick only
one, I would choose the :foo method. :)
> As for contortions, well I am thinking of large program environments
> here where data dictionaries and generated SQL are the norm. Having
> this feature allows for more elegant yet fast generated SQL.
The can already generate the SQL without a database connection. I guess
the real advantage is in pre-parsing the SQL and turning it into a
form more amenable to passing to the database server, by quoting values
and/or changing placeholder forms. I could possibly see a place for this,
and I like the option of allowing some things to possible be done before
the database is connected, but I don't really see much of a real-world
time saving. But where would this method live? It obviously could not
be called via $dbh->compile, nor could it be DBI->compile. You would
almost need a new connection mtehod, or perhaps a flag on the current
connect() method that tells the driver to load, but defer actually
conecting to the database.
>> I *know* we aren't talking about a >global SQL parser - that way lies
>> madness. :)
> Are you sure about that? I am making such a thing right now. I
> certainly don't expect DBI to have that built in, but it would be
> nice for DBI to be structured that it is easier to build one on top.
> And Tim explicitly said he wants input towards making DBI effective
> for people putting layers on top of it.
Sure, I have no problem with making things more extensible, but the
implication was that the DBI would be doing SQL parsing directly,
which is not the route to go. I just want to make sure that we keep
DBI as an abstraction layer. Additional hooks are fine: additional
tasks are not.
>> A $sth should not contain any methods for fetching the result of
>> an executed statement;
>...
>> my $rlh = $sth->execute();
>> my $rowset = $rlh->fetchrow_arrayref();
At the very least, you'll need a different interface, as execute()
already returns a value (number of rows affected).
> Not to me. I see a statement as a program function. You prepare it,
> invoke it with arguments, and it returns a result. The result is
> separate from the function.
I see a statement as an object. The results are attributes of the statement
object, and there are methods for getting at that information. The
results are closely tied to that particular statement, so disassociating
them gains nothing, and adds possible confusion. And what do call finish()
with - rlh or sth?
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200507100855
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFC0SELvJuQZxSWSsgRAnSzAJ9V1kgJ1M/7U56hvIcKi6/HhEevBwCgvdli
Roud86HrkgU+7dNnfqygwc4=
=GN3E
-----END PGP SIGNATURE-----
