On Thursday 07 February 2008 11:07, Jeff Rogers wrote:
> [EMAIL PROTECTED] wrote:
> > The select proc is only in the pg driver in order to support some ancient
> > AOLserver 2 functionality that I doubt anyone else uses any more.
>
> Then should it be removed? (in someone's copious free time...)
>
> > It shouldn't appear in your sqllite3 driver, IMO.
>
> Could you expand on this? You've got way more experience with the db
> drivers than I do so I'm inclined to take your advice, but I'm curious
> why you think a unified exec is better than separate select/dml/generic
> functions.
The ns_db API allows you to use ns_db exec exclusively, you don't need the
other API. If you use ns_db exec, you can provide error detection and
recovery closer to the application layer instead of embedding it in the
driver. Here is a simple example:
set ExecCode [ns_db exec $dbHandle $PreparedQuery]
set ReturnList [list]
set Level [incr level]
switch -exact -- "$ExecCode" {
"NS_DML" {
set ReturnList [list -1]
}
"NS_ROWS" {
set RowSet [ns_db bindrow $dbHandle]
set Rows 0
while {[ns_db getrow $dbHandle $RowSet]} {
incr Rows
set Array "${arrayTemplate}${Rows}"
upvar $Level $Array A${Rows}
if {![info exists Cols]} {
set Cols [ns_set size $RowSet]
}
for {set i 0} {$i < $Cols} {incr i} {
set A${Rows}([ns_set key $RowSet $i]) "[ns_set value $RowSet
$i]"
}
lappend ReturnList $Array
}
}
}
return $ReturnList
If an error occurs the whole thing errors out, but the caller can handle
certain things like ns_db 1row, when the row can only appear once, but is
missing, in other words, if you use ns_db 0or1row, you would still have to
check which you get, and with 1row you would have to catch the error. So
there is no benefit for these specialized select API. (They may be a little
more clear for those reading the code what you are trying to do, but that is
about it.)
tom jackson
> Aside from that, do you also think the generic function should be
> preferred over the specific function if both are defined?
>
> > I suggest you implement stephen deasy's straightforward check that
> > differentiates between queries that return rows (i.e. SELECT queries but
> > usig SQL Lite's parser) to differentiate between NS_ROWS and NS_DML
> > queries.
> >
> > As far as security goes, no one should allow for the direct execution of
> > external SQL anyway, not even a SELECT. If someone's code breaks because
> > they execute a "DROP TABLE" statement sent to their site via a query
> > string or whatever, there's not much reason to have sympathy for them.
>
> Yes, everyone should check their inputs to avoid this, but things
> sometimes slip through. What I worry about is a high-profile
> sql-injection vulnerability being discovered leading to manager-esque
> types saying "AOLserver is inherently insecure because of how it handles
> database queries, so we can't use it." (It hasn't slowed down php tho.)
>
> One of my few gripes about the ns_db interface is that you can only pass
> raw sql instead of being able to use bind variables. It makes the
> correct code more verbose and the simple code insecure. I wish I could
> write my queries as
> ns_db select $db "select * from users where id = ?" $user
> instead of
> ns_db select $db "select * from users where id = [ns_dbquotevalue $user]"
> Yes, it's a straightforward wrapper function to do that (although you
> wouldn't get the performance benefits from a stored prepared statement
> that are theoretically possible) but having it as core functionality
> would be nicer.
>
> -J
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the
> email message. You can leave the Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
