On Nov 2, 2007, at 15:11 , mike wrote:
I'd strongly recommend you to use bindings *before* you
find out
you're wrong about the control you're exercising. Someday you'll be
entering data for Little Bobby Tables and everything will go terribly
wrong. The price of protection is *really* low, and in many cases
can make things much faster.
By parameter binding are you talking about using prepared statements
in the SQL queries?
I have never had any of my applications that I can remember suffer
from SQL injection. I always use mysql_escape_string, the PHP filter
functions on POST and GET data, type checking and bounds checking (for
numeric information)
Don't confuse not having someone exploit a vulnerability (or not
knowing that it's been done) with not having one. I'm quite certain
you have a vulnerability and you've just been lucky that nobody's
found it yet.
That's not to say it couldn't happen but that is lower on my priority
list and something the language already provides. I was looking to
address the cache stuff here.
Understood. This middle part is definitely OT.
I do have a generic cache_get() wrapper, I just plan on having _set
_get etc. type functions for each type of data interaction. In theory
I could just put in the function name in the cache_get() as a
callback, but I do like having control, sometimes a function like
user_get needs some additional work, not just a raw SELECT * FROM
table WHERE user_id=$id.
Yes, that's exactly how I designed the sample code I showed
you. :) The ``cache miss'' code doesn't necessarily have to use a
DB at all (I do this kind of stuff in one of my apps where the data
I'm caching come from digg).
...but you're working really hard to optimize for a case
that you
haven't proven causes any issues in your application.
That is to say, if PHP is so incredibly bad at iterating a
small
array that you would work this hard to avoid it, why would anyone
ever use it?
I think PHP is already fast, but obviously no matter what language it
is, if the code is trying to work with too much data or is written
like crap, it's going to be slow.
djb has a pretty nicely written paper out mostly about the topic of
security in qmail, but has some really good general programming points:
http://cr.yp.to/qmail/qmailsec-20071101.pdf
Section 2.6 refers to speed as a distraction that prevents us from
writing better software and begins with a classic Knuth quote:
Programmers waste enormous amounts of time thinking about, or
worrying about,
the speed of noncritical parts of their programs, and these attempts at
efficiency actually have a strong negative impact when debugging and
maintenance are considered. We should forget about small
efficiencies, say
about 97% of the time; premature optimization is the root of all evil.
I have a very nice generic non-pipelining function set already
written, this thread was aimed to address trying to move it into
pipelineable/multiget-compatible code, and it seemed like having to do
multiple iterations and creating two or more arrays was overkill, once
I noticed the key prefixes were complicating things.
Good, you've got a baseline, then. :) I'd expect you'd find it
easier to build your abstractions in your scripting language than in
C. Once you get them nailed down to where they're exactly right, and
you can detect whether they're slow, then you can try to rewrite them
and see if you can make them fast enough.
--
Dustin Sallings
